From 4132723a104c59daca842c1e13fdf34ed6a43cd9 Mon Sep 17 00:00:00 2001 From: Miguel Angel Reina Ortega Date: Thu, 20 Nov 2025 16:13:12 +0100 Subject: [PATCH] Added new version v5.3.1 --- v5.3.1/SOL002-APIVersion-API.json | 1 + v5.3.1/SOL002-APIVersion-API.yaml | 10313 ++ v5.3.1/SOL002-VNFConfiguration-API.json | 1 + v5.3.1/SOL002-VNFConfiguration-API.yaml | 5107 + v5.3.1/SOL002-VNFFaultManagement-API.json | 1 + v5.3.1/SOL002-VNFFaultManagement-API.yaml | 13365 ++ ...02-VNFFaultManagementNotification-API.json | 1 + ...02-VNFFaultManagementNotification-API.yaml | 4899 + v5.3.1/SOL002-VNFIndicator-API.json | 1 + v5.3.1/SOL002-VNFIndicator-API.yaml | 10747 ++ .../SOL002-VNFIndicatorNotification-API.json | 1 + .../SOL002-VNFIndicatorNotification-API.yaml | 3079 + .../SOL002-VNFLifecycleCoordination-API.json | 1 + .../SOL002-VNFLifecycleCoordination-API.yaml | 6034 + v5.3.1/SOL002-VNFLifecycleManagement-API.json | 1 + v5.3.1/SOL002-VNFLifecycleManagement-API.yaml | 88774 ++++++++++++ ...NFLifecycleManagementNotification-API.json | 1 + ...NFLifecycleManagementNotification-API.yaml | 6703 + .../SOL002-VNFPerformanceManagement-API.json | 1 + .../SOL002-VNFPerformanceManagement-API.yaml | 17033 +++ ...PerformanceManagementNotification-API.json | 1 + ...PerformanceManagementNotification-API.yaml | 3128 + v5.3.1/SOL003-APIVersion-API.json | 1 + v5.3.1/SOL003-APIVersion-API.yaml | 13743 ++ v5.3.1/SOL003-VNFFaultManagement-API.json | 1 + v5.3.1/SOL003-VNFFaultManagement-API.yaml | 11430 ++ ...03-VNFFaultManagementNotification-API.json | 1 + ...03-VNFFaultManagementNotification-API.yaml | 4989 + v5.3.1/SOL003-VNFIndicator-API.json | 1 + v5.3.1/SOL003-VNFIndicator-API.yaml | 10160 ++ .../SOL003-VNFIndicatorNotification-API.json | 1 + .../SOL003-VNFIndicatorNotification-API.yaml | 1670 + v5.3.1/SOL003-VNFLifecycleManagement-API.json | 1 + v5.3.1/SOL003-VNFLifecycleManagement-API.yaml | 103790 +++++++++++++++ ...NFLifecycleManagementNotification-API.json | 1 + ...NFLifecycleManagementNotification-API.yaml | 6786 + ...003-VNFLifecycleOperationGranting-API.json | 1 + ...003-VNFLifecycleOperationGranting-API.yaml | 12026 ++ v5.3.1/SOL003-VNFPackageManagement-API.json | 1 + v5.3.1/SOL003-VNFPackageManagement-API.yaml | 21959 +++ ...-VNFPackageManagementNotification-API.json | 1 + ...-VNFPackageManagementNotification-API.yaml | 3186 + .../SOL003-VNFPerformanceManagement-API.json | 1 + .../SOL003-VNFPerformanceManagement-API.yaml | 15648 +++ ...PerformanceManagementNotification-API.json | 1 + ...PerformanceManagementNotification-API.yaml | 3188 + ...L003-VNFSnapshotPackageManagement-API.json | 1 + ...L003-VNFSnapshotPackageManagement-API.yaml | 7810 ++ ...sourcesQuotaAvailableNotification-API.json | 1 + ...sourcesQuotaAvailableNotification-API.yaml | 6522 + 50 files changed, 392114 insertions(+) create mode 100644 v5.3.1/SOL002-APIVersion-API.json create mode 100644 v5.3.1/SOL002-APIVersion-API.yaml create mode 100644 v5.3.1/SOL002-VNFConfiguration-API.json create mode 100644 v5.3.1/SOL002-VNFConfiguration-API.yaml create mode 100644 v5.3.1/SOL002-VNFFaultManagement-API.json create mode 100644 v5.3.1/SOL002-VNFFaultManagement-API.yaml create mode 100644 v5.3.1/SOL002-VNFFaultManagementNotification-API.json create mode 100644 v5.3.1/SOL002-VNFFaultManagementNotification-API.yaml create mode 100644 v5.3.1/SOL002-VNFIndicator-API.json create mode 100644 v5.3.1/SOL002-VNFIndicator-API.yaml create mode 100644 v5.3.1/SOL002-VNFIndicatorNotification-API.json create mode 100644 v5.3.1/SOL002-VNFIndicatorNotification-API.yaml create mode 100644 v5.3.1/SOL002-VNFLifecycleCoordination-API.json create mode 100644 v5.3.1/SOL002-VNFLifecycleCoordination-API.yaml create mode 100644 v5.3.1/SOL002-VNFLifecycleManagement-API.json create mode 100644 v5.3.1/SOL002-VNFLifecycleManagement-API.yaml create mode 100644 v5.3.1/SOL002-VNFLifecycleManagementNotification-API.json create mode 100644 v5.3.1/SOL002-VNFLifecycleManagementNotification-API.yaml create mode 100644 v5.3.1/SOL002-VNFPerformanceManagement-API.json create mode 100644 v5.3.1/SOL002-VNFPerformanceManagement-API.yaml create mode 100644 v5.3.1/SOL002-VNFPerformanceManagementNotification-API.json create mode 100644 v5.3.1/SOL002-VNFPerformanceManagementNotification-API.yaml create mode 100644 v5.3.1/SOL003-APIVersion-API.json create mode 100644 v5.3.1/SOL003-APIVersion-API.yaml create mode 100644 v5.3.1/SOL003-VNFFaultManagement-API.json create mode 100644 v5.3.1/SOL003-VNFFaultManagement-API.yaml create mode 100644 v5.3.1/SOL003-VNFFaultManagementNotification-API.json create mode 100644 v5.3.1/SOL003-VNFFaultManagementNotification-API.yaml create mode 100644 v5.3.1/SOL003-VNFIndicator-API.json create mode 100644 v5.3.1/SOL003-VNFIndicator-API.yaml create mode 100644 v5.3.1/SOL003-VNFIndicatorNotification-API.json create mode 100644 v5.3.1/SOL003-VNFIndicatorNotification-API.yaml create mode 100644 v5.3.1/SOL003-VNFLifecycleManagement-API.json create mode 100644 v5.3.1/SOL003-VNFLifecycleManagement-API.yaml create mode 100644 v5.3.1/SOL003-VNFLifecycleManagementNotification-API.json create mode 100644 v5.3.1/SOL003-VNFLifecycleManagementNotification-API.yaml create mode 100644 v5.3.1/SOL003-VNFLifecycleOperationGranting-API.json create mode 100644 v5.3.1/SOL003-VNFLifecycleOperationGranting-API.yaml create mode 100644 v5.3.1/SOL003-VNFPackageManagement-API.json create mode 100644 v5.3.1/SOL003-VNFPackageManagement-API.yaml create mode 100644 v5.3.1/SOL003-VNFPackageManagementNotification-API.json create mode 100644 v5.3.1/SOL003-VNFPackageManagementNotification-API.yaml create mode 100644 v5.3.1/SOL003-VNFPerformanceManagement-API.json create mode 100644 v5.3.1/SOL003-VNFPerformanceManagement-API.yaml create mode 100644 v5.3.1/SOL003-VNFPerformanceManagementNotification-API.json create mode 100644 v5.3.1/SOL003-VNFPerformanceManagementNotification-API.yaml create mode 100644 v5.3.1/SOL003-VNFSnapshotPackageManagement-API.json create mode 100644 v5.3.1/SOL003-VNFSnapshotPackageManagement-API.yaml create mode 100644 v5.3.1/SOL003-VirtualisedResourcesQuotaAvailableNotification-API.json create mode 100644 v5.3.1/SOL003-VirtualisedResourcesQuotaAvailableNotification-API.yaml diff --git a/v5.3.1/SOL002-APIVersion-API.json b/v5.3.1/SOL002-APIVersion-API.json new file mode 100644 index 00000000..941250e3 --- /dev/null +++ b/v5.3.1/SOL002-APIVersion-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL002 - API version interface","description":"SOL002 - API version Interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"1.3.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 002 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/05.03.01_60/gs_NFV-SOL002v050301p.pdf"},"paths":{"/vnfconfig/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnffm/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnfind/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnflcm/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnfpm/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/lcmcoord/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}}} diff --git a/v5.3.1/SOL002-APIVersion-API.yaml b/v5.3.1/SOL002-APIVersion-API.yaml new file mode 100644 index 00000000..b446de6e --- /dev/null +++ b/v5.3.1/SOL002-APIVersion-API.yaml @@ -0,0 +1,10313 @@ +openapi: 3.0.2 +info: + title: SOL002 - API version interface + description: | + SOL002 - API version Interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '1.3.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 002 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/05.03.01_60/gs_NFV-SOL002v050301p.pdf +paths: + /vnfconfig/api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /vnffm/api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /vnfind/api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /vnflcm/api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /vnfpm/api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /lcmcoord/api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + diff --git a/v5.3.1/SOL002-VNFConfiguration-API.json b/v5.3.1/SOL002-VNFConfiguration-API.json new file mode 100644 index 00000000..3b3877a0 --- /dev/null +++ b/v5.3.1/SOL002-VNFConfiguration-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL002 - VNF Configuration interface","description":"SOL002 - VNF Configuration Interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"1.12.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 002 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/05.03.01_60/gs_NFV-SOL002v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/vnfconfig/v1"},{"url":"https://127.0.0.1/vnfconfig/v1"}],"paths":{"/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/configuration":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The API consumer can use this method to read configuration information about a VNF instance and/or its VNFC instances.\nSee clause 9.4.2.3.2.\n","responses":{"200":{"$ref":"#/components/responses/Configuration.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method sets or modifies a configuration resource. See clause 9.4.2.3.4.\n","parameters":[{"name":"If-Unmodified-Since","description":"Used to make the request method conditional on the selected resource representation's last modification date being earlier than or equal to the date provided in the field-value. If the condition is not met, the request fails with a \"412 Precondition Failed\" response.\n","required":false,"in":"header","schema":{"type":"string","format":"date-time"}},{"name":"If-Match","description":"Used to make the request method conditional on the recipient origin server either having at least one current representation of the target resource, when the field-value is \"*\", or having a current representation of the target resource that has an entity-tag matching a member of the list of entity-tags provided in the field-value. If the condition is not met, the request fails with a \"412 Precondition Failed\" response.\n","required":false,"in":"header","schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/ConfigurationRequest"},"responses":{"200":{"$ref":"#/components/responses/Configuration.Patch.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"412 PRECONDITION FAILED\nError: 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"requestBodies":{"ConfigurationRequest":{"description":"The parameter for the configuration modification, as defined in clause 9.5.2.2.\n","content":{"application/json":{"schema":{"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","anyOf":[{"required":["vnfConfigurationData"]},{"required":["vnfcConfigurationData"]}],"properties":{"vnfConfigurationData":{"description":"This type represents configuration parameters of a VNF instance. * NOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of\n the VNFD based on TOSCA specifications.\n","type":"object","properties":{"extCpConfig":{"description":"Configuration parameters for the external CPs of the VNF 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","oneOf":[{"required":["address"]},{"required":["useDynamicAddress"]}],"anyOf":[{"required":["macAddress"]},{"required":["ipAddress"]}],"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"}}}}}}},"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 keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\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.\nNOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\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","oneOf":[{"required":["address"]},{"required":["useDynamicAddress"]}],"anyOf":[{"required":["macAddress"]},{"required":["ipAddress"]}],"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"}}}}}}},"certificateData":{"description":"Certificates data to be configured or modified into VNFC instance. Shall be present if delegation-mode is used. Otherwise it shall be absent.\n","type":"array","items":{"description":"This type provides input information related to subject of certificate.\nNOTE : Either set of “privatekey” and “certificateFile” or “keystoreFile” but not both shall be present.\n","type":"object","properties":{"privateKey":{"type":"string","description":"Private key paired with the signed public key. VNFM shall generate both the private key and public key and set this attribute. See note.\n"},"certificateFile":{"type":"string","description":"Signed certificate including the public key and certificate chain. See note.\n"},"keystoreFile":{"type":"string","description":"Keystore which includes the private key, signed certificate, and certificate chain (e.g., pkcs#12, pfx). Credentials to read this file shall be provided to the VNF instance by outbound. See note.\n"},"certSubjectData":{"description":"This type provides input information related to subject of certificate.\n* NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of certification target subject FQDN. See note.","type":"string"},"organization":{"description":"Information of certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of certification target subject Country. See note.","type":"string"},"state":{"description":"Information of certification target subject State. See note.","type":"string"},"locality":{"description":"Information of certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of certification contact email address. See note.","type":"string"}}},"certifiateProfileName":{"type":"string","description":"Name of the certificate profile to be signed.\n"}}}},"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 keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"vnfcConfigurationDataDeleteIds":{"description":"List of identifiers entries to be deleted from the 'vnfcConfigurationData\" attribute array to be used as \"deleteIdList\" as defined below this table.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}}},"required":true}},"responses":{"Configuration.Get.200":{"description":"200 OK\nShall be returned when configuration information about a VNF instance has been read successfully. The response\nbody shall contain a representation of the configuration resource.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.\n","style":"simple","explode":false,"schema":{"type":"string"}},"ETag":{"description":"Used to provide the current entity-tag for the selected resource representation. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string"}},"Last-Modified":{"description":"Used to provide a timestamp indicating the date and time at which the server believes the selected resource representation was last modified. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string","format":"date-time"}}},"content":{"application/json":{"schema":{"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. * NOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of\n the VNFD based on TOSCA specifications.\n","type":"object","properties":{"extCpConfig":{"description":"Configuration parameters for the external CPs of the VNF 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","oneOf":[{"required":["address"]},{"required":["useDynamicAddress"]}],"anyOf":[{"required":["macAddress"]},{"required":["ipAddress"]}],"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"}}}}}}},"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 keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\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.\nNOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\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","oneOf":[{"required":["address"]},{"required":["useDynamicAddress"]}],"anyOf":[{"required":["macAddress"]},{"required":["ipAddress"]}],"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"}}}}}}},"certificateData":{"description":"Certificates data to be configured or modified into VNFC instance. Shall be present if delegation-mode is used. Otherwise it shall be absent.\n","type":"array","items":{"description":"This type provides input information related to subject of certificate.\nNOTE : Either set of “privatekey” and “certificateFile” or “keystoreFile” but not both shall be present.\n","type":"object","properties":{"privateKey":{"type":"string","description":"Private key paired with the signed public key. VNFM shall generate both the private key and public key and set this attribute. See note.\n"},"certificateFile":{"type":"string","description":"Signed certificate including the public key and certificate chain. See note.\n"},"keystoreFile":{"type":"string","description":"Keystore which includes the private key, signed certificate, and certificate chain (e.g., pkcs#12, pfx). Credentials to read this file shall be provided to the VNF instance by outbound. See note.\n"},"certSubjectData":{"description":"This type provides input information related to subject of certificate.\n* NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of certification target subject FQDN. See note.","type":"string"},"organization":{"description":"Information of certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of certification target subject Country. See note.","type":"string"},"state":{"description":"Information of certification target subject State. See note.","type":"string"},"locality":{"description":"Information of certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of certification contact email address. See note.","type":"string"}}},"certifiateProfileName":{"type":"string","description":"Name of the certificate profile to be signed.\n"}}}},"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 keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}}}}},"Configuration.Patch.200":{"description":"200 OK\nShall be returned when the request has been accepted and completed. The response body shall contain the\nparameters of the configuration modification that was applied to the configuration resource.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"ETag":{"description":"Used to provide the current entity-tag for the selected resource representation. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string"}},"Last-Modified":{"description":"Used to provide a timestamp indicating the date and time at which the server believes the selected resource representation was last modified. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string","format":"date-time"}}},"content":{"application/json":{"schema":{"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","anyOf":[{"required":["vnfConfigurationData"]},{"required":["vnfcConfigurationData"]}],"properties":{"vnfConfigurationData":{"description":"This type represents configuration parameters of a VNF instance. * NOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of\n the VNFD based on TOSCA specifications.\n","type":"object","properties":{"extCpConfig":{"description":"Configuration parameters for the external CPs of the VNF 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","oneOf":[{"required":["address"]},{"required":["useDynamicAddress"]}],"anyOf":[{"required":["macAddress"]},{"required":["ipAddress"]}],"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"}}}}}}},"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 keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\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.\nNOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\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","oneOf":[{"required":["address"]},{"required":["useDynamicAddress"]}],"anyOf":[{"required":["macAddress"]},{"required":["ipAddress"]}],"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"}}}}}}},"certificateData":{"description":"Certificates data to be configured or modified into VNFC instance. Shall be present if delegation-mode is used. Otherwise it shall be absent.\n","type":"array","items":{"description":"This type provides input information related to subject of certificate.\nNOTE : Either set of “privatekey” and “certificateFile” or “keystoreFile” but not both shall be present.\n","type":"object","properties":{"privateKey":{"type":"string","description":"Private key paired with the signed public key. VNFM shall generate both the private key and public key and set this attribute. See note.\n"},"certificateFile":{"type":"string","description":"Signed certificate including the public key and certificate chain. See note.\n"},"keystoreFile":{"type":"string","description":"Keystore which includes the private key, signed certificate, and certificate chain (e.g., pkcs#12, pfx). Credentials to read this file shall be provided to the VNF instance by outbound. See note.\n"},"certSubjectData":{"description":"This type provides input information related to subject of certificate.\n* NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of certification target subject FQDN. See note.","type":"string"},"organization":{"description":"Information of certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of certification target subject Country. See note.","type":"string"},"state":{"description":"Information of certification target subject State. See note.","type":"string"},"locality":{"description":"Information of certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of certification contact email address. See note.","type":"string"}}},"certifiateProfileName":{"type":"string","description":"Name of the certificate profile to be signed.\n"}}}},"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 keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"vnfcConfigurationDataDeleteIds":{"description":"List of identifiers entries to be deleted from the 'vnfcConfigurationData\" attribute array to be used as \"deleteIdList\" as defined below this table.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}}}}}}} diff --git a/v5.3.1/SOL002-VNFConfiguration-API.yaml b/v5.3.1/SOL002-VNFConfiguration-API.yaml new file mode 100644 index 00000000..48c86aae --- /dev/null +++ b/v5.3.1/SOL002-VNFConfiguration-API.yaml @@ -0,0 +1,5107 @@ +openapi: 3.0.2 +info: + title: SOL002 - VNF Configuration interface + description: | + SOL002 - VNF Configuration Interface + + IMPORTANT: Please note that this file might be not aligned to the current + version of the ETSI Group Specification it refers to. In case of + discrepancies the published ETSI Group Specification takes precedence. + + Please report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '1.12.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 002 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/05.03.01_60/gs_NFV-SOL002v050301p.pdf +servers: + - url: 'http://127.0.0.1/vnfconfig/v1' + - url: 'https://127.0.0.1/vnfconfig/v1' +paths: + /api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /configuration: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The API consumer can use this method to read configuration information + about a VNF instance and/or its VNFC instances. + + See clause 9.4.2.3.2. + responses: + '200': + $ref: '#/components/responses/Configuration.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method sets or modifies a configuration resource. See clause + 9.4.2.3.4. + parameters: + - name: If-Unmodified-Since + description: > + Used to make the request method conditional on the selected + resource representation's last modification date being earlier than + or equal to the date provided in the field-value. If the condition + is not met, the request fails with a "412 Precondition Failed" + response. + required: false + in: header + schema: + type: string + format: date-time + - name: If-Match + description: > + Used to make the request method conditional on the recipient origin + server either having at least one current representation of the + target resource, when the field-value is "*", or having a current + representation of the target resource that has an entity-tag + matching a member of the list of entity-tags provided in the + field-value. If the condition is not met, the request fails with a + "412 Precondition Failed" response. + required: false + in: header + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/ConfigurationRequest' + responses: + '200': + $ref: '#/components/responses/Configuration.Patch.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 412 PRECONDITION FAILED + + Error: A precondition given in an HTTP request header is not + fulfilled. Typically, this is due to an ETag mismatch, indicating + that the resource was modified by another entity. The response body + should contain a ProblemDetails structure, in which the "detail" + attribute should convey more information about the error. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + requestBodies: + ConfigurationRequest: + description: > + The parameter for the configuration modification, as defined in clause + 9.5.2.2. + content: + application/json: + schema: + 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 + anyOf: + - required: + - vnfConfigurationData + - required: + - vnfcConfigurationData + properties: + vnfConfigurationData: + description: "This type represents configuration parameters of a VNF instance. * NOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of\n the VNFD based on TOSCA specifications.\n" + type: object + properties: + extCpConfig: + description: > + Configuration parameters for the external CPs of the VNF + 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 + oneOf: + - required: + - address + - required: + - useDynamicAddress + anyOf: + - required: + - macAddress + - required: + - ipAddress + 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 + 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 keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + 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.\nNOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\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. + 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 + oneOf: + - required: + - address + - required: + - useDynamicAddress + anyOf: + - required: + - macAddress + - required: + - ipAddress + 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 + certificateData: + description: > + Certificates data to be configured or modified into VNFC + instance. Shall be present if delegation-mode is used. + Otherwise it shall be absent. + type: array + items: + description: > + This type provides input information related to + subject of certificate. + + NOTE : Either set of “privatekey” and + “certificateFile” or “keystoreFile” but not both shall + be present. + type: object + properties: + privateKey: + type: string + description: > + Private key paired with the signed public key. + VNFM shall generate both the private key and + public key and set this attribute. See note. + certificateFile: + type: string + description: > + Signed certificate including the public key and + certificate chain. See note. + keystoreFile: + type: string + description: > + Keystore which includes the private key, signed + certificate, and certificate chain (e.g., pkcs#12, + pfx). Credentials to read this file shall be + provided to the VNF instance by outbound. See + note. + certSubjectData: + description: > + This type provides input information related to + subject of certificate. + + * NOTE: At least one overriding attributes shall + be present, otherwise shall be absent. + type: object + properties: + commonName: + description: >- + Information of certification target subject + FQDN. See note. + type: string + organization: + description: >- + Information of certification target subject + Organization. See note. + type: string + country: + description: >- + Information of certification target subject + Country. See note. + type: string + state: + description: >- + Information of certification target subject + State. See note. + type: string + locality: + description: >- + Information of certification target subject + Locality. See note. + type: string + emailAddress: + description: >- + Information of certification contact email + address. See note. + type: string + certifiateProfileName: + type: string + description: | + Name of the certificate profile to be signed. + 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 keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + vnfcConfigurationDataDeleteIds: + description: > + List of identifiers entries to be deleted from the + 'vnfcConfigurationData" attribute array to be used as + "deleteIdList" as defined below this table. + type: array + items: + description: | + An identifier with the intention of being globally unique. + type: string + required: true + responses: + Configuration.Get.200: + description: > + 200 OK + + Shall be returned when configuration information about a VNF instance + has been read successfully. The response + + body shall contain a representation of the configuration resource. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + ETag: + description: > + Used to provide the current entity-tag for the selected resource + representation. It can be sent in "200 OK", "201 Created" and "204 + No Content" responses. + style: simple + schema: + type: string + Last-Modified: + description: > + Used to provide a timestamp indicating the date and time at which + the server believes the selected resource representation was last + modified. It can be sent in "200 OK", "201 Created" and "204 No + Content" responses. + style: simple + schema: + type: string + format: date-time + content: + application/json: + schema: + 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. * NOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of\n the VNFD based on TOSCA specifications.\n" + type: object + properties: + extCpConfig: + description: > + Configuration parameters for the external CPs of the VNF + 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 + oneOf: + - required: + - address + - required: + - useDynamicAddress + anyOf: + - required: + - macAddress + - required: + - ipAddress + 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 + 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 keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + vnfcConfigurationData: + description: | + Configuration parameters of the VNFC instances. + type: array + items: + description: "This type represents configuration parameters of a VNFC instance.\nNOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\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. + 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 + oneOf: + - required: + - address + - required: + - useDynamicAddress + anyOf: + - required: + - macAddress + - required: + - ipAddress + 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 + certificateData: + description: > + Certificates data to be configured or modified into VNFC + instance. Shall be present if delegation-mode is used. + Otherwise it shall be absent. + type: array + items: + description: > + This type provides input information related to + subject of certificate. + + NOTE : Either set of “privatekey” and + “certificateFile” or “keystoreFile” but not both shall + be present. + type: object + properties: + privateKey: + type: string + description: > + Private key paired with the signed public key. + VNFM shall generate both the private key and + public key and set this attribute. See note. + certificateFile: + type: string + description: > + Signed certificate including the public key and + certificate chain. See note. + keystoreFile: + type: string + description: > + Keystore which includes the private key, signed + certificate, and certificate chain (e.g., pkcs#12, + pfx). Credentials to read this file shall be + provided to the VNF instance by outbound. See + note. + certSubjectData: + description: > + This type provides input information related to + subject of certificate. + + * NOTE: At least one overriding attributes shall + be present, otherwise shall be absent. + type: object + properties: + commonName: + description: >- + Information of certification target subject + FQDN. See note. + type: string + organization: + description: >- + Information of certification target subject + Organization. See note. + type: string + country: + description: >- + Information of certification target subject + Country. See note. + type: string + state: + description: >- + Information of certification target subject + State. See note. + type: string + locality: + description: >- + Information of certification target subject + Locality. See note. + type: string + emailAddress: + description: >- + Information of certification contact email + address. See note. + type: string + certifiateProfileName: + type: string + description: | + Name of the certificate profile to be signed. + 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 keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + Configuration.Patch.200: + description: > + 200 OK + + Shall be returned when the request has been accepted and completed. The + response body shall contain the + + parameters of the configuration modification that was applied to the + configuration resource. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + ETag: + description: > + Used to provide the current entity-tag for the selected resource + representation. It can be sent in "200 OK", "201 Created" and "204 + No Content" responses. + style: simple + schema: + type: string + Last-Modified: + description: > + Used to provide a timestamp indicating the date and time at which + the server believes the selected resource representation was last + modified. It can be sent in "200 OK", "201 Created" and "204 No + Content" responses. + style: simple + schema: + type: string + format: date-time + content: + application/json: + schema: + 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 + anyOf: + - required: + - vnfConfigurationData + - required: + - vnfcConfigurationData + properties: + vnfConfigurationData: + description: "This type represents configuration parameters of a VNF instance. * NOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of\n the VNFD based on TOSCA specifications.\n" + type: object + properties: + extCpConfig: + description: > + Configuration parameters for the external CPs of the VNF + 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 + oneOf: + - required: + - address + - required: + - useDynamicAddress + anyOf: + - required: + - macAddress + - required: + - ipAddress + 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 + 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 keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + 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.\nNOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\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. + 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 + oneOf: + - required: + - address + - required: + - useDynamicAddress + anyOf: + - required: + - macAddress + - required: + - ipAddress + 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 + certificateData: + description: > + Certificates data to be configured or modified into VNFC + instance. Shall be present if delegation-mode is used. + Otherwise it shall be absent. + type: array + items: + description: > + This type provides input information related to + subject of certificate. + + NOTE : Either set of “privatekey” and + “certificateFile” or “keystoreFile” but not both shall + be present. + type: object + properties: + privateKey: + type: string + description: > + Private key paired with the signed public key. + VNFM shall generate both the private key and + public key and set this attribute. See note. + certificateFile: + type: string + description: > + Signed certificate including the public key and + certificate chain. See note. + keystoreFile: + type: string + description: > + Keystore which includes the private key, signed + certificate, and certificate chain (e.g., pkcs#12, + pfx). Credentials to read this file shall be + provided to the VNF instance by outbound. See + note. + certSubjectData: + description: > + This type provides input information related to + subject of certificate. + + * NOTE: At least one overriding attributes shall + be present, otherwise shall be absent. + type: object + properties: + commonName: + description: >- + Information of certification target subject + FQDN. See note. + type: string + organization: + description: >- + Information of certification target subject + Organization. See note. + type: string + country: + description: >- + Information of certification target subject + Country. See note. + type: string + state: + description: >- + Information of certification target subject + State. See note. + type: string + locality: + description: >- + Information of certification target subject + Locality. See note. + type: string + emailAddress: + description: >- + Information of certification contact email + address. See note. + type: string + certifiateProfileName: + type: string + description: | + Name of the certificate profile to be signed. + 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 keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + vnfcConfigurationDataDeleteIds: + description: > + List of identifiers entries to be deleted from the + 'vnfcConfigurationData" attribute array to be used as + "deleteIdList" as defined below this table. + type: array + items: + description: | + An identifier with the intention of being globally unique. + type: string + diff --git a/v5.3.1/SOL002-VNFFaultManagement-API.json b/v5.3.1/SOL002-VNFFaultManagement-API.json new file mode 100644 index 00000000..5ba8ebf8 --- /dev/null +++ b/v5.3.1/SOL002-VNFFaultManagement-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL002 - VNF Fault Management interface","description":"SOL002 - VNF Fault Management interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"1.14.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 002 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/05.03.01_60/gs_NFV-SOL002v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/vnffm/v1"},{"url":"https://127.0.0.1/vnffm/v1"}],"paths":{"/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/alarms":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The API consumer can use this method to retrieve information about the alarm list. See clause 7.4.2.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}},{"$ref":"#/components/parameters/filter_alarms"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [6] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/Alarms.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/alarms/{alarmId}":{"parameters":[{"$ref":"#/components/parameters/AlarmId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The API consumer can use this method to read an individual alarm. See clause 7.4.3.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualAlarm.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method modifies an individual alarm resource. See clause 7.4.3.3.4.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"If-Unmodified-Since","description":"Used to make the request method conditional on the selected resource representation's last modification date being earlier than or equal to the date provided in the field-value. If the condition is not met, the request fails with a \"412 Precondition Failed\" response.\n","required":false,"in":"header","schema":{"type":"string","format":"date-time"}},{"name":"If-Match","description":"Used to make the request method conditional on the recipient origin server either having at least one current representation of the target resource, when the field-value is \"*\", or having a current representation of the target resource that has an entity-tag matching a member of the list of entity-tags provided in the field-value. If the condition is not met, the request fails with a \"412 Precondition Failed\" response.\n","required":false,"in":"header","schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/IndividualAlarmRequest"},"responses":{"200":{"$ref":"#/components/responses/IndividualAlarm.Patch.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/IndividualAlarm.Patch.409"},"412":{"description":"412 PRECONDITION FAILED\nError: 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/alarms/{alarmId}/escalate":{"parameters":[{"$ref":"#/components/parameters/AlarmId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"The POST method enables the API consumer to escalate the perceived severity of an alarm that is represented\nby an individual alarm resource. See clause 7.4.4.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/IndividualAlarmEscalateRequest"},"responses":{"204":{"$ref":"#/components/responses/IndividualAlarmEscalate.Post.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/subscriptions":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The API consumer can use this method to retrieve the list of active subscriptions for VNF alarms subscribed\nby the API consumer. It can be used e.g. for resynchronization after error situations. See clause 7.4.5.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}},{"$ref":"#/components/parameters/filter_subscriptions"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [6] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/Subscriptions.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"The POST method creates a new subscription. See clause 7.4.5.3.1.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/FmSubscriptionRequest"},"responses":{"201":{"$ref":"#/components/responses/Subscriptions.Post.201"},"303":{"description":"303 See Other\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/Subscriptions.Post.422"},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/subscriptions/{subscriptionId}":{"parameters":[{"$ref":"#/components/parameters/SubscriptionId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The API consumer can use this method for reading an individual subscription for VNF alarms subscribed\nby the API consumer. See clause 7.4.6.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualSubscription.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method terminates an individual subscription. See clause 7.4.6.3.5.\n","responses":{"204":{"$ref":"#/components/responses/IndividualSubscription.Delete.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"parameters":{"filter_subscriptions":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013. The VNFM shall support receiving this parameter as part of the URI query string. The EM may supply this parameter. The VNF may supply its instance Id as an attribute filter. All attribute names that appear in the FmSubscription and in data types referenced from it shall be supported by the VNFM in the filter expression\n","in":"query","required":false,"schema":{"type":"string"}},"filter_alarms":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013. The VNFM shall support receiving this parameter as part of the URI query string. The EM may supply this parameter. The VNF may supply its instance Id as an attribute filter. The following attribute names shall be supported in the filter expression: id, managedObjectId, vnfcInstanceIds, rootCauseFaultyResource.faultyResourceType, eventType, perceivedSeverity, probableCause. If the vnfcInstanceIds parameter is provided, exactly one value for the managedObjectId attribute shall be provided.\n","in":"query","required":false,"schema":{"type":"string"}},"AlarmId":{"name":"alarmId","in":"path","description":"Identifier of the alarm. This identifier can be retrieved from the \"id\" attribute of the \"alarm\" attribute\nin the AlarmNotification or AlarmClearedNotification. It can also be retrieved from the \"id\" attribute of\nthe applicable array element in the message content of the response to a GET request to the \"Alarms\" resource.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"SubscriptionId":{"name":"subscriptionId","in":"path","description":"Identifier of this subscription. This identifier can be retrieved from the resource referenced by the \"Location\"\nHTTP header in the response to a POST request creating a new subscription resource. It can also be retrieved\nfrom the \"id\" attribute in the message content of that response.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}}},"requestBodies":{"IndividualAlarmRequest":{"description":"The parameter for the alarm modification","content":{"application/merge-patch+json":{"schema":{"description":"This type represents attribute modifications for an \"Individual alarm\" resource, i.e. modifications to a resource representation based on the \"Alarm\" data type. The attributes of \"Alarm\" that can be modified are included in the \"AlarmModifications\" data type.\n","type":"object","required":["ackState"],"properties":{"ackState":{"description":"New value of the \"ackState\" attribute in \"Alarm\". Permitted values: * ACKNOWLEDGED * UNACKNOWLEDGED\n","type":"string","enum":["ACKNOWLEDGED","UNACKNOWLEDGED"]}}}}},"required":true},"IndividualAlarmEscalateRequest":{"description":"The proposed \"escalated perceived severity\" value","content":{"application/json":{"schema":{"description":"This type represents the escalated value of the perceived severity for an alarm.\n","type":"object","required":["proposedPerceivedSeverity"],"properties":{"proposedPerceivedSeverity":{"description":"Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n","type":"string","enum":["CRITICAL","MAJOR","MINOR","WARNING","INDETERMINATE","CLEARED"]}}}}},"required":false},"FmSubscriptionRequest":{"description":"The VNF creation parameters","content":{"application/json":{"schema":{"description":"This type represents a subscription request related to notifications about VNF faults.\n","type":"object","required":["callbackUri"],"properties":{"filter":{"description":"This type represents a subscription filter related to notifications about VNF faults.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdIds"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tAlarmNotification -\tAlarmClearedNotification -\tAlarmListRebuiltNotification See note.\n","type":"array","items":{"type":"string","enum":["AlarmNotification","AlarmClearedNotification","AlarmListRebuiltNotification"]}},"faultyResourceTypes":{"description":"Match VNF alarms with a faulty resource type listed in this attribute.\n","type":"array","items":{"description":"The enumeration FaultyResourceType represents those types of faulty resource.\n","type":"string","enum":["COMPUTE","STORAGE","NETWORK"]}},"perceivedSeverities":{"description":"Match VNF alarms with a perceived severity listed in this attribute.\n","type":"array","items":{"description":"Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n","type":"string","enum":["CRITICAL","MAJOR","MINOR","WARNING","INDETERMINATE","CLEARED"]}},"eventTypes":{"description":"Match VNF alarms with an event type listed in this attribute.\n","type":"array","items":{"description":"The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment fault (ITU-T Recommendation X.733).\n","type":"string","enum":["COMMUNICATIONS_ALARM","PROCESSING_ERROR_ALARM","ENVIRONMENTAL_ALARM","QOS_ALARM","EQUIPMENT_ALARM"]}},"probableCauses":{"description":"Match VNF alarms with a probable cause listed in this attribute.\n","type":"array","items":{"type":"string"}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE 1 : The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between\n subscriptions. The value of clientPassword should be generated by a random process.\n* NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT which uses mutual authentication based on X.509 certificates, this mode which uses client password to authenticate may be used in the access token request\n toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations\n (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details.\n* NOTE 3: The following values that were included up to version 3.4.1 of the present document have been removed: \"BASIC\" (to signal the use of the basic HTTP authentication) has been removed because it is insecure.\n \"TLS_CERT\" to signal an alternative non-token based authorization method using TLS certificates has been\n removed because the method is no longer supported.\n* NOTE 4: The client certificate is established by means outside the scope of the present document.\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values (see note 3): * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use\n an OAuth 2.0 token, obtained using the client\n credentials grant type after authenticating\n using client identifier and client password\n towards the token endpoint.\n* OAUTH2_CLIENT_CERT: In every HTTP request to the notification endpoint, use an\n OAuth 2.0 token, obtained using the client\n credentials grant type after mutually\n authenticating using client identifier and X.509\n certificates towards the token endpoint.\n","type":"array","items":{"type":"string","enum":["OAUTH2_CLIENT_CREDENTIALS","OAUTH2_CLIENT_CERT"]}},"paramsOauth2ClientCert":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CERT.\nShall be present if authType is \"OAUTH2_CLIENT_CERT\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\n","type":"object","required":["clientId","certificateRef","tokenEndpoint"],"properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint.\n","type":"string"},"certificateRef":{"description":"Fingerprint of the client certificate. The hash function shall use SHA256 or higher. See note 4.\n","type":"string","required":["type","value"],"properties":{"type":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"value":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS.\nShall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\nSee note 2.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"clientPassword":{"description":"Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true}},"responses":{"Alarms.Get.200":{"description":"200 OK\nShall be returned when information about zero or more alarms was queried successfully. The response body shall\ncontain in an array the representations of zero or more alarms as defined in clause 7.5.2.4. If the \"filter\"\nURI parameter was supplied in the request, the data in the response body shall have been transformed according\nto the rules specified in clause 5.2.2 of ETSI GS NFV-SOL 013. If the VNFM supports alternative 2 (paging)\naccording to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource, inclusion of the Link HTTP header in this\nresponse shall follow the provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The alarm data type encapsulates information about an alarm.\nIf the attribute \"faultType\" has the value \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE\", the following provisions apply for the values of the attribute \"faultDetails\" related to changes in the state of virtualised resources: - One of the entries in the array shall provide information about the anticipated time of maintenance in the\n following format: \"anticipatedTime=$time\", wherein \"$time\" shall be formatted as a \"DateTime\", as specified\n in ETSI GS NFV-SOL 013.\n - One of the entries in the array shall provide identification information about the affinity/anti-affinity group\n defined in the VNFD that is associated to the affected virtualised resource indicated by \"rootCauseFaultyResource\" \n in the following format: \"affinityOrAntiAffinityGroupId=$group\", wherein \"$group\" shall be equal to the \n \"affinityOrAntiAffinityGroupId\" value in the corresponding \"VduProfile\" (for a VNFC/COMPUTE affected resource) \n or \"VirtualLinkProfile\" for a VL/NETWORK affected resource) in the VNFD, which is mapped by the VNFM to the \n virtualised resource group identifier in the virtualised resource change notification received by the VNFM from \n the VIM.\n\nNOTE 1: For an alarm about upcoming impact due to NFVI operation and maintenance (i.e. the attribute \"faultType\" has the value \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE\"), the attribute \"rootCauseFaultyResource\" \n indicates a resource to be impacted. Further information on the upcoming impact (e.g. group of impacted \n resources, time of impact) is provided in the attribute \"faultDetails\".\nNOTE 2: When alarms are due to upcoming NFVI operation and maintenance (i.e. the attribute \"faultType\" has the value \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE\"), the attribute \"faultDetails\" shall include information \n about the anticipated time of the maintenance. See provisions under the present table.\n","type":"object","required":["id","managedObjectId","alarmRaisedTime","ackState","perceivedSeverity","eventTime","eventType","probableCause","isRootCause","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"managedObjectId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcInstanceIds":{"description":"Identifiers of the affected VNFC instances. Each identifier references the \"id\" attribute in a \"VnfcInfo\" structure. Shall be present if the alarm affects at least one VNFC instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"rootCauseFaultyResource":{"description":"This type represents the faulty virtual resources that have a negative impact on a VNF.\n","type":"object","required":["faultyResource","faultyResourceType"],"properties":{"faultyResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"faultyResourceType":{"description":"The enumeration FaultyResourceType represents those types of faulty resource.\n","type":"string","enum":["COMPUTE","STORAGE","NETWORK"]}}},"alarmRaisedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"alarmChangedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"alarmClearedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"alarmAcknowledgedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"ackState":{"description":"Acknowledgement state of the alarm. Permitted values: * UNACKNOWLEDGED * ACKNOWLEDGED.\n","type":"string","enum":["UNACKNOWLEDGED","ACKNOWLEDGED"]},"perceivedSeverity":{"description":"Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n","type":"string","enum":["CRITICAL","MAJOR","MINOR","WARNING","INDETERMINATE","CLEARED"]},"eventTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"eventType":{"description":"The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment fault (ITU-T Recommendation X.733).\n","type":"string","enum":["COMMUNICATIONS_ALARM","PROCESSING_ERROR_ALARM","ENVIRONMENTAL_ALARM","QOS_ALARM","EQUIPMENT_ALARM"]},"faultType":{"description":"Additional information to clarify the type of the fault. Valid values applicable to specific Alarms are specified as \"Alarm definition identifier\" values of the Alarm applicable to Ve-Vnfm reference point. If the alarm is related to changes in the state of virtualised resources due to NFVI operation and maintenance, this attribute shall be set to \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE _CHANGE\".\n","type":"string"},"probableCause":{"description":"Information about the probable cause of the fault. Valid values applicable to specific Alarms are specified as \"Probable cause\" values of the Alarm applicable to Ve-Vnfm reference point. If the attribute \"faultType\" has the value “NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE”, the permitted values are: - \"NFVI_COMPONENT_MAINTENANCE\": Maintenance of NFVI components, e.g. physical maintenance/repair, \n hypervisor software updates, etc.\n - \"NFVI_COMPONENT_EVACUATION\": Evacuation of physical hosts.\n - \"NFVI_COMPONENT_OPTIMIZATION\": Operation and management of NFVI resources, e.g. to support energy\n efficiency or resource usage optimization.\n","type":"string"},"isRootCause":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"correlatedAlarmIds":{"description":"List of identifiers of other alarms correlated to this fault.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"faultDetails":{"description":"Provides additional information about the fault. See notes 1 and 2. Valid values applicable to specific Alarms are specified as \"Fault details\" values of the Alarm applicable to Ve-Vnfm reference point.\n","type":"array","items":{"type":"string"}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"objectInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualAlarm.Get.200":{"description":"200 OK\nShall be returned when information about an individual alarm read successfully. The response body shall contain\na representation of the individual alarm.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"ETag":{"description":"Used to provide the current entity-tag for the selected resource representation. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string"}},"Last-Modified":{"description":"Used to provide a timestamp indicating the date and time at which the server believes the selected resource representation was last modified. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string","format":"date-time"}}},"content":{"application/json":{"schema":{"description":"The alarm data type encapsulates information about an alarm.\nIf the attribute \"faultType\" has the value \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE\", the following provisions apply for the values of the attribute \"faultDetails\" related to changes in the state of virtualised resources: - One of the entries in the array shall provide information about the anticipated time of maintenance in the\n following format: \"anticipatedTime=$time\", wherein \"$time\" shall be formatted as a \"DateTime\", as specified\n in ETSI GS NFV-SOL 013.\n - One of the entries in the array shall provide identification information about the affinity/anti-affinity group\n defined in the VNFD that is associated to the affected virtualised resource indicated by \"rootCauseFaultyResource\" \n in the following format: \"affinityOrAntiAffinityGroupId=$group\", wherein \"$group\" shall be equal to the \n \"affinityOrAntiAffinityGroupId\" value in the corresponding \"VduProfile\" (for a VNFC/COMPUTE affected resource) \n or \"VirtualLinkProfile\" for a VL/NETWORK affected resource) in the VNFD, which is mapped by the VNFM to the \n virtualised resource group identifier in the virtualised resource change notification received by the VNFM from \n the VIM.\n\nNOTE 1: For an alarm about upcoming impact due to NFVI operation and maintenance (i.e. the attribute \"faultType\" has the value \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE\"), the attribute \"rootCauseFaultyResource\" \n indicates a resource to be impacted. Further information on the upcoming impact (e.g. group of impacted \n resources, time of impact) is provided in the attribute \"faultDetails\".\nNOTE 2: When alarms are due to upcoming NFVI operation and maintenance (i.e. the attribute \"faultType\" has the value \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE\"), the attribute \"faultDetails\" shall include information \n about the anticipated time of the maintenance. See provisions under the present table.\n","type":"object","required":["id","managedObjectId","alarmRaisedTime","ackState","perceivedSeverity","eventTime","eventType","probableCause","isRootCause","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"managedObjectId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcInstanceIds":{"description":"Identifiers of the affected VNFC instances. Each identifier references the \"id\" attribute in a \"VnfcInfo\" structure. Shall be present if the alarm affects at least one VNFC instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"rootCauseFaultyResource":{"description":"This type represents the faulty virtual resources that have a negative impact on a VNF.\n","type":"object","required":["faultyResource","faultyResourceType"],"properties":{"faultyResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"faultyResourceType":{"description":"The enumeration FaultyResourceType represents those types of faulty resource.\n","type":"string","enum":["COMPUTE","STORAGE","NETWORK"]}}},"alarmRaisedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"alarmChangedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"alarmClearedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"alarmAcknowledgedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"ackState":{"description":"Acknowledgement state of the alarm. Permitted values: * UNACKNOWLEDGED * ACKNOWLEDGED.\n","type":"string","enum":["UNACKNOWLEDGED","ACKNOWLEDGED"]},"perceivedSeverity":{"description":"Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n","type":"string","enum":["CRITICAL","MAJOR","MINOR","WARNING","INDETERMINATE","CLEARED"]},"eventTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"eventType":{"description":"The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment fault (ITU-T Recommendation X.733).\n","type":"string","enum":["COMMUNICATIONS_ALARM","PROCESSING_ERROR_ALARM","ENVIRONMENTAL_ALARM","QOS_ALARM","EQUIPMENT_ALARM"]},"faultType":{"description":"Additional information to clarify the type of the fault. Valid values applicable to specific Alarms are specified as \"Alarm definition identifier\" values of the Alarm applicable to Ve-Vnfm reference point. If the alarm is related to changes in the state of virtualised resources due to NFVI operation and maintenance, this attribute shall be set to \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE _CHANGE\".\n","type":"string"},"probableCause":{"description":"Information about the probable cause of the fault. Valid values applicable to specific Alarms are specified as \"Probable cause\" values of the Alarm applicable to Ve-Vnfm reference point. If the attribute \"faultType\" has the value “NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE”, the permitted values are: - \"NFVI_COMPONENT_MAINTENANCE\": Maintenance of NFVI components, e.g. physical maintenance/repair, \n hypervisor software updates, etc.\n - \"NFVI_COMPONENT_EVACUATION\": Evacuation of physical hosts.\n - \"NFVI_COMPONENT_OPTIMIZATION\": Operation and management of NFVI resources, e.g. to support energy\n efficiency or resource usage optimization.\n","type":"string"},"isRootCause":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"correlatedAlarmIds":{"description":"List of identifiers of other alarms correlated to this fault.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"faultDetails":{"description":"Provides additional information about the fault. See notes 1 and 2. Valid values applicable to specific Alarms are specified as \"Fault details\" values of the Alarm applicable to Ve-Vnfm reference point.\n","type":"array","items":{"type":"string"}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"objectInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualAlarm.Patch.200":{"description":"200 OK\nShall be returned when the request was accepted and completed. The response body shall contain attribute\nmodifications for an \"Individual alarm\" resource.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"ETag":{"description":"Used to provide the current entity-tag for the selected resource representation. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string"}},"Last-Modified":{"description":"Used to provide a timestamp indicating the date and time at which the server believes the selected resource representation was last modified. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string","format":"date-time"}}},"content":{"application/json":{"schema":{"description":"This type represents attribute modifications for an \"Individual alarm\" resource, i.e. modifications to a resource representation based on the \"Alarm\" data type. The attributes of \"Alarm\" that can be modified are included in the \"AlarmModifications\" data type.\n","type":"object","required":["ackState"],"properties":{"ackState":{"description":"New value of the \"ackState\" attribute in \"Alarm\". Permitted values: * ACKNOWLEDGED * UNACKNOWLEDGED\n","type":"string","enum":["ACKNOWLEDGED","UNACKNOWLEDGED"]}}}}}},"IndividualAlarm.Patch.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the \"Individual alarm\"\nresource.\nTypically, this is due to the fact that the alarm is\nalready in the state that is requested to be set (such\nas trying to acknowledge an already-acknowledged\nalarm).\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualAlarmEscalate.Post.204":{"description":"204 No Content\nShall be returned when the VNFM has received the proposed \"escalated perceived severity\" value successfully.\nThe response body shall be empty.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{}},"Subscriptions.Get.200":{"description":"200 OK\nShall be returned when the list of subscriptions has been queried successfully.\nThe response body shall contain the representations of all active subscriptions of the functional block that\ninvokes the method. If the \"filter\" URI parameter was supplied in the request, the data in the response body\nshall have been transformed according to the rules specified in clause 5.2.2 of ETSI GS NFV-SOL 013.\nIf the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource,\ninclusion of the Link HTTP header in this response shall follow the provisions in clause 5.4.2.3 of\nETSI GS NFV-SOL 013.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a subscription related to notifications about VNF faults.\n","type":"object","required":["id","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications about VNF faults.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdIds"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tAlarmNotification -\tAlarmClearedNotification -\tAlarmListRebuiltNotification See note.\n","type":"array","items":{"type":"string","enum":["AlarmNotification","AlarmClearedNotification","AlarmListRebuiltNotification"]}},"faultyResourceTypes":{"description":"Match VNF alarms with a faulty resource type listed in this attribute.\n","type":"array","items":{"description":"The enumeration FaultyResourceType represents those types of faulty resource.\n","type":"string","enum":["COMPUTE","STORAGE","NETWORK"]}},"perceivedSeverities":{"description":"Match VNF alarms with a perceived severity listed in this attribute.\n","type":"array","items":{"description":"Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n","type":"string","enum":["CRITICAL","MAJOR","MINOR","WARNING","INDETERMINATE","CLEARED"]}},"eventTypes":{"description":"Match VNF alarms with an event type listed in this attribute.\n","type":"array","items":{"description":"The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment fault (ITU-T Recommendation X.733).\n","type":"string","enum":["COMMUNICATIONS_ALARM","PROCESSING_ERROR_ALARM","ENVIRONMENTAL_ALARM","QOS_ALARM","EQUIPMENT_ALARM"]}},"probableCauses":{"description":"Match VNF alarms with a probable cause listed in this attribute.\n","type":"array","items":{"type":"string"}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"fmConnection":{"description":"An access information and interface information to monitor the FM of VNF instance by the VNFM. This can include for instance certain interface endpoint URI together with necessary credentials to access it.\n","type":"array","items":{"description":"The MonitoringConnection shall follow the indications. * NOTE:\tThe VNFM can be made aware of monitoring connection information, including their identifiers to \n be used by configuration means outside the scope of the present document (e.g. using relevant NFV-MANO management \n APIs as defined in ETSI GS NFV-SOL 009). \n","type":"object","required":["id","monitoringType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"monitoringType":{"description":"Type of monitoring way. VALUES: \n •\tVIM_CISM\n •\tEXTERNAL\n •\tPAAS\n","type":"string","enum":["VIM_CISM","EXTERNAL","PAAS"]},"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"Subscriptions.Post.201":{"description":"201 CREATED\nThe subscription was created successfully. The response body shall contain a representation of the created\nsubscription resource. The HTTP response shall include a \"Location:\" HTTP header that points to the created\nsubscription resource.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{"application/json":{"schema":{"description":"This type represents a subscription related to notifications about VNF faults.\n","type":"object","required":["id","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications about VNF faults.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdIds"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tAlarmNotification -\tAlarmClearedNotification -\tAlarmListRebuiltNotification See note.\n","type":"array","items":{"type":"string","enum":["AlarmNotification","AlarmClearedNotification","AlarmListRebuiltNotification"]}},"faultyResourceTypes":{"description":"Match VNF alarms with a faulty resource type listed in this attribute.\n","type":"array","items":{"description":"The enumeration FaultyResourceType represents those types of faulty resource.\n","type":"string","enum":["COMPUTE","STORAGE","NETWORK"]}},"perceivedSeverities":{"description":"Match VNF alarms with a perceived severity listed in this attribute.\n","type":"array","items":{"description":"Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n","type":"string","enum":["CRITICAL","MAJOR","MINOR","WARNING","INDETERMINATE","CLEARED"]}},"eventTypes":{"description":"Match VNF alarms with an event type listed in this attribute.\n","type":"array","items":{"description":"The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment fault (ITU-T Recommendation X.733).\n","type":"string","enum":["COMMUNICATIONS_ALARM","PROCESSING_ERROR_ALARM","ENVIRONMENTAL_ALARM","QOS_ALARM","EQUIPMENT_ALARM"]}},"probableCauses":{"description":"Match VNF alarms with a probable cause listed in this attribute.\n","type":"array","items":{"type":"string"}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"fmConnection":{"description":"An access information and interface information to monitor the FM of VNF instance by the VNFM. This can include for instance certain interface endpoint URI together with necessary credentials to access it.\n","type":"array","items":{"description":"The MonitoringConnection shall follow the indications. * NOTE:\tThe VNFM can be made aware of monitoring connection information, including their identifiers to \n be used by configuration means outside the scope of the present document (e.g. using relevant NFV-MANO management \n APIs as defined in ETSI GS NFV-SOL 009). \n","type":"object","required":["id","monitoringType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"monitoringType":{"description":"Type of monitoring way. VALUES: \n •\tVIM_CISM\n •\tEXTERNAL\n •\tPAAS\n","type":"string","enum":["VIM_CISM","EXTERNAL","PAAS"]},"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"Subscriptions.Post.422":{"description":"422 Unprocessable Content\n\nShall be returned upon the following error: The content type of the message content is supported\nand the message content of a request contains syntactically correct data but the data cannot be processed.\nThe general cause for this error and its handling is specified in clause 6.4 of ETSI GS NFV-SOL 013,\nincluding rules for the presence of the response body.\nSpecifically in case of this resource, the response code 422 shall also be returned if the VNFM has tested\nthe Notification endpoint as described in clause 7.4.7.3.2 and the test has failed.\nIn this case, the \"detail\" attribute in the \"ProblemDetails\" structure shall convey more information\nabout the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualSubscription.Get.200":{"description":"200 OK\nShall be returned when information about an individual subscription has been read successfully.\nThe response body shall contain a representation of the \"Individual subscription\" resource.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error\ndetails if the corresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a subscription related to notifications about VNF faults.\n","type":"object","required":["id","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications about VNF faults.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdIds"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tAlarmNotification -\tAlarmClearedNotification -\tAlarmListRebuiltNotification See note.\n","type":"array","items":{"type":"string","enum":["AlarmNotification","AlarmClearedNotification","AlarmListRebuiltNotification"]}},"faultyResourceTypes":{"description":"Match VNF alarms with a faulty resource type listed in this attribute.\n","type":"array","items":{"description":"The enumeration FaultyResourceType represents those types of faulty resource.\n","type":"string","enum":["COMPUTE","STORAGE","NETWORK"]}},"perceivedSeverities":{"description":"Match VNF alarms with a perceived severity listed in this attribute.\n","type":"array","items":{"description":"Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n","type":"string","enum":["CRITICAL","MAJOR","MINOR","WARNING","INDETERMINATE","CLEARED"]}},"eventTypes":{"description":"Match VNF alarms with an event type listed in this attribute.\n","type":"array","items":{"description":"The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment fault (ITU-T Recommendation X.733).\n","type":"string","enum":["COMMUNICATIONS_ALARM","PROCESSING_ERROR_ALARM","ENVIRONMENTAL_ALARM","QOS_ALARM","EQUIPMENT_ALARM"]}},"probableCauses":{"description":"Match VNF alarms with a probable cause listed in this attribute.\n","type":"array","items":{"type":"string"}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"fmConnection":{"description":"An access information and interface information to monitor the FM of VNF instance by the VNFM. This can include for instance certain interface endpoint URI together with necessary credentials to access it.\n","type":"array","items":{"description":"The MonitoringConnection shall follow the indications. * NOTE:\tThe VNFM can be made aware of monitoring connection information, including their identifiers to \n be used by configuration means outside the scope of the present document (e.g. using relevant NFV-MANO management \n APIs as defined in ETSI GS NFV-SOL 009). \n","type":"object","required":["id","monitoringType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"monitoringType":{"description":"Type of monitoring way. VALUES: \n •\tVIM_CISM\n •\tEXTERNAL\n •\tPAAS\n","type":"string","enum":["VIM_CISM","EXTERNAL","PAAS"]},"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualSubscription.Delete.204":{"description":"204 NO CONTENT\nShall be returned when the \"Individual subscription\" resource has been deleted successfully.\nThe response body shall be empty.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{}}}}} diff --git a/v5.3.1/SOL002-VNFFaultManagement-API.yaml b/v5.3.1/SOL002-VNFFaultManagement-API.yaml new file mode 100644 index 00000000..bba16a4a --- /dev/null +++ b/v5.3.1/SOL002-VNFFaultManagement-API.yaml @@ -0,0 +1,13365 @@ +openapi: 3.0.2 +info: + title: SOL002 - VNF Fault Management interface + description: | + SOL002 - VNF Fault Management interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '1.14.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 002 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/05.03.01_60/gs_NFV-SOL002v050301p.pdf +servers: + - url: 'http://127.0.0.1/vnffm/v1' + - url: 'https://127.0.0.1/vnffm/v1' +paths: + /api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /alarms: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The API consumer can use this method to retrieve information about the + alarm list. See clause 7.4.2.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + - $ref: '#/components/parameters/filter_alarms' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [6] for this + resource. + in: query + required: false + schema: + type: string + responses: + '200': + $ref: '#/components/responses/Alarms.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/alarms/{alarmId}': + parameters: + - $ref: '#/components/parameters/AlarmId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The API consumer can use this method to read an individual alarm. See + clause 7.4.3.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualAlarm.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: | + This method modifies an individual alarm resource. See clause 7.4.3.3.4. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + - name: If-Unmodified-Since + description: > + Used to make the request method conditional on the selected + resource representation's last modification date being earlier than + or equal to the date provided in the field-value. If the condition + is not met, the request fails with a "412 Precondition Failed" + response. + required: false + in: header + schema: + type: string + format: date-time + - name: If-Match + description: > + Used to make the request method conditional on the recipient origin + server either having at least one current representation of the + target resource, when the field-value is "*", or having a current + representation of the target resource that has an entity-tag + matching a member of the list of entity-tags provided in the + field-value. If the condition is not met, the request fails with a + "412 Precondition Failed" response. + required: false + in: header + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/IndividualAlarmRequest' + responses: + '200': + $ref: '#/components/responses/IndividualAlarm.Patch.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/IndividualAlarm.Patch.409' + '412': + description: > + 412 PRECONDITION FAILED + + Error: A precondition given in an HTTP request header is not + fulfilled. Typically, this is due to an ETag mismatch, indicating + that the resource was modified by another entity. The response body + should contain a ProblemDetails structure, in which the "detail" + attribute should convey more information about the error. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/alarms/{alarmId}/escalate': + parameters: + - $ref: '#/components/parameters/AlarmId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + post: + description: > + The POST method enables the API consumer to escalate the perceived + severity of an alarm that is represented + + by an individual alarm resource. See clause 7.4.4.3.1. + requestBody: + $ref: '#/components/requestBodies/IndividualAlarmEscalateRequest' + responses: + '204': + $ref: '#/components/responses/IndividualAlarmEscalate.Post.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /subscriptions: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The API consumer can use this method to retrieve the list of active + subscriptions for VNF alarms subscribed + + by the API consumer. It can be used e.g. for resynchronization after + error situations. See clause 7.4.5.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + - $ref: '#/components/parameters/filter_subscriptions' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [6] for this + resource. + in: query + required: false + schema: + type: string + responses: + '200': + $ref: '#/components/responses/Subscriptions.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: | + The POST method creates a new subscription. See clause 7.4.5.3.1. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/FmSubscriptionRequest' + responses: + '201': + $ref: '#/components/responses/Subscriptions.Post.201' + '303': + description: | + 303 See Other + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/Subscriptions.Post.422' + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/subscriptions/{subscriptionId}': + parameters: + - $ref: '#/components/parameters/SubscriptionId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The API consumer can use this method for reading an individual + subscription for VNF alarms subscribed + + by the API consumer. See clause 7.4.6.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualSubscription.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: | + This method terminates an individual subscription. See clause 7.4.6.3.5. + responses: + '204': + $ref: '#/components/responses/IndividualSubscription.Delete.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + parameters: + filter_subscriptions: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013. The VNFM shall support receiving this parameter as part of + the URI query string. The EM may supply this parameter. The VNF may + supply its instance Id as an attribute filter. All attribute names that + appear in the FmSubscription and in data types referenced from it shall + be supported by the VNFM in the filter expression + in: query + required: false + schema: + type: string + filter_alarms: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013. The VNFM shall support receiving this parameter as part of + the URI query string. The EM may supply this parameter. The VNF may + supply its instance Id as an attribute filter. The following attribute + names shall be supported in the filter expression: id, managedObjectId, + vnfcInstanceIds, rootCauseFaultyResource.faultyResourceType, eventType, + perceivedSeverity, probableCause. If the vnfcInstanceIds parameter is + provided, exactly one value for the managedObjectId attribute shall be + provided. + in: query + required: false + schema: + type: string + AlarmId: + name: alarmId + in: path + description: > + Identifier of the alarm. This identifier can be retrieved from the "id" + attribute of the "alarm" attribute + + in the AlarmNotification or AlarmClearedNotification. It can also be + retrieved from the "id" attribute of + + the applicable array element in the message content of the response to a + GET request to the "Alarms" resource. + required: true + style: simple + explode: false + schema: + type: string + SubscriptionId: + name: subscriptionId + in: path + description: > + Identifier of this subscription. This identifier can be retrieved from + the resource referenced by the "Location" + + HTTP header in the response to a POST request creating a new + subscription resource. It can also be retrieved + + from the "id" attribute in the message content of that response. + required: true + style: simple + explode: false + schema: + type: string + requestBodies: + IndividualAlarmRequest: + description: The parameter for the alarm modification + content: + application/merge-patch+json: + schema: + description: > + This type represents attribute modifications for an "Individual + alarm" resource, i.e. modifications to a resource representation + based on the "Alarm" data type. The attributes of "Alarm" that can + be modified are included in the "AlarmModifications" data type. + type: object + required: + - ackState + properties: + ackState: + description: > + New value of the "ackState" attribute in "Alarm". Permitted + values: * ACKNOWLEDGED * UNACKNOWLEDGED + type: string + enum: + - ACKNOWLEDGED + - UNACKNOWLEDGED + required: true + IndividualAlarmEscalateRequest: + description: The proposed "escalated perceived severity" value + content: + application/json: + schema: + description: > + This type represents the escalated value of the perceived severity + for an alarm. + type: object + required: + - proposedPerceivedSeverity + properties: + proposedPerceivedSeverity: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level indicates + that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a service + affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the detection + of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level indicates + that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the clearing + of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + required: false + FmSubscriptionRequest: + description: The VNF creation parameters + content: + application/json: + schema: + description: > + This type represents a subscription request related to + notifications about VNF faults. + type: object + required: + - callbackUri + properties: + filter: + description: "This type represents a subscription filter related to notifications about VNF faults.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdIds + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId values + listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, from + one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tAlarmNotification -\tAlarmClearedNotification -\tAlarmListRebuiltNotification See note.\n" + type: array + items: + type: string + enum: + - AlarmNotification + - AlarmClearedNotification + - AlarmListRebuiltNotification + faultyResourceTypes: + description: > + Match VNF alarms with a faulty resource type listed in + this attribute. + type: array + items: + description: > + The enumeration FaultyResourceType represents those + types of faulty resource. + type: string + enum: + - COMPUTE + - STORAGE + - NETWORK + perceivedSeverities: + description: > + Match VNF alarms with a perceived severity listed in this + attribute. + type: array + items: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level + indicates that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a + service affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the + existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the + detection of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level + indicates that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the + clearing of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTypes: + description: > + Match VNF alarms with an event type listed in this + attribute. + type: array + items: + description: > + The enumeration EventType represents those types of + events that trigger an alarm. * COMMUNICATIONS_ALARM: An + alarm of this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is + associated with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is + associated with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated + with an equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + probableCauses: + description: > + Match VNF alarms with a probable cause listed in this + attribute. + type: array + items: + type: string + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + authentication: + description: > + * NOTE 1 : The clientId and clientPassword passed in a + subscription shall not be the same as the clientId and + clientPassword that are used to obtain authorization for API requests. Client credentials may differ between + subscriptions. The value of clientPassword should be generated by a random process. + * NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT + which uses mutual authentication based on X.509 + certificates, this mode which uses client password to authenticate may be used in the access token request + toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations + (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details. + * NOTE 3: The following values that were included up to + version 3.4.1 of the present document have been removed: + "BASIC" (to signal the use of the basic HTTP authentication) has been removed because it is insecure. + "TLS_CERT" to signal an alternative non-token based authorization method using TLS certificates has been + removed because the method is no longer supported. + * NOTE 4: The client certificate is established by means + outside the scope of the present document. + type: object + required: + - authType + properties: + authType: + description: > + Defines the types of Authentication / Authorization which + the API consumer is willing to accept when receiving a + notification. Permitted values (see note 3): * + OAUTH2_CLIENT_CREDENTIALS: In every + HTTP request to the notification endpoint, use + an OAuth 2.0 token, obtained using the client + credentials grant type after authenticating + using client identifier and client password + towards the token endpoint. + * OAUTH2_CLIENT_CERT: In every HTTP + request to the notification endpoint, use an + OAuth 2.0 token, obtained using the client + credentials grant type after mutually + authenticating using client identifier and X.509 + certificates towards the token endpoint. + type: array + items: + type: string + enum: + - OAUTH2_CLIENT_CREDENTIALS + - OAUTH2_CLIENT_CERT + paramsOauth2ClientCert: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CERT. + + Shall be present if authType is "OAUTH2_CLIENT_CERT" and + the contained information has not been provisioned out of + band. + + Shall be absent otherwise. + type: object + required: + - clientId + - certificateRef + - tokenEndpoint + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. + type: string + certificateRef: + description: > + Fingerprint of the client certificate. The hash + function shall use SHA256 or higher. See note 4. + type: string + required: + - type + - value + properties: + type: + description: | + A string defined in IETF RFC 8259. + type: string + value: + description: | + A string defined in IETF RFC 8259. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + paramsOauth2ClientCredentials: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CREDENTIALS. + + Shall be present if authType is + "OAUTH2_CLIENT_CREDENTIALS" and the contained information + has not been provisioned out of band. + + Shall be absent otherwise. + + See note 2. + type: object + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. Shall be present if it has not been + provisioned out of band. See note 1. + type: string + clientPassword: + description: > + Client password to be used in the access token request + of the OAuth 2.0 client credentials grant type. Shall + be present if it has not been provisioned out of band. + See note 1. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + responses: + Alarms.Get.200: + description: > + 200 OK + + Shall be returned when information about zero or more alarms was queried + successfully. The response body shall + + contain in an array the representations of zero or more alarms as + defined in clause 7.5.2.4. If the "filter" + + URI parameter was supplied in the request, the data in the response + body shall have been transformed according + + to the rules specified in clause 5.2.2 of ETSI GS NFV-SOL 013. If the + VNFM supports alternative 2 (paging) + + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource, + inclusion of the Link HTTP header in this + + response shall follow the provisions in clause 5.4.2.3 of ETSI GS + NFV-SOL 013. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The alarm data type encapsulates information about an alarm. + + If the attribute "faultType" has the value + "NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE", the following + provisions apply for the values of the attribute "faultDetails" + related to changes in the state of virtualised resources: + - One of the entries in the array shall provide information about the anticipated time of maintenance in the + following format: "anticipatedTime=$time", wherein "$time" shall be formatted as a "DateTime", as specified + in ETSI GS NFV-SOL 013. + - One of the entries in the array shall provide identification information about the affinity/anti-affinity group + defined in the VNFD that is associated to the affected virtualised resource indicated by "rootCauseFaultyResource" + in the following format: "affinityOrAntiAffinityGroupId=$group", wherein "$group" shall be equal to the + "affinityOrAntiAffinityGroupId" value in the corresponding "VduProfile" (for a VNFC/COMPUTE affected resource) + or "VirtualLinkProfile" for a VL/NETWORK affected resource) in the VNFD, which is mapped by the VNFM to the + virtualised resource group identifier in the virtualised resource change notification received by the VNFM from + the VIM. + + NOTE 1: For an alarm about upcoming impact due to NFVI operation + and maintenance (i.e. the attribute "faultType" + has the value "NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE"), the attribute "rootCauseFaultyResource" + indicates a resource to be impacted. Further information on the upcoming impact (e.g. group of impacted + resources, time of impact) is provided in the attribute "faultDetails". + NOTE 2: When alarms are due to upcoming NFVI operation and + maintenance (i.e. the attribute "faultType" has the + value "NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE"), the attribute "faultDetails" shall include information + about the anticipated time of the maintenance. See provisions under the present table. + type: object + required: + - id + - managedObjectId + - alarmRaisedTime + - ackState + - perceivedSeverity + - eventTime + - eventType + - probableCause + - isRootCause + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + managedObjectId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfcInstanceIds: + description: > + Identifiers of the affected VNFC instances. Each identifier + references the "id" attribute in a "VnfcInfo" structure. + Shall be present if the alarm affects at least one VNFC + instance. + type: array + items: + description: > + An identifier that is unique for the respective type within + a VNF instance, but may not be globally unique. + type: string + rootCauseFaultyResource: + description: > + This type represents the faulty virtual resources that have a + negative impact on a VNF. + type: object + required: + - faultyResource + - faultyResourceType + properties: + faultyResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available from + the VIM. + + * NOTE 1: The information about the VIM or CISM connection + referenced by the VIM connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service is a + Kubernetes® instance the resourceId shall be populated in + the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is allocated. + It shall be present for compute resources in the + scope of the CISM and shall be absent otherwise. + See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is managed + by a CISM and it shall be absent otherwise. + type: string + faultyResourceType: + description: > + The enumeration FaultyResourceType represents those types + of faulty resource. + type: string + enum: + - COMPUTE + - STORAGE + - NETWORK + alarmRaisedTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + alarmChangedTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + alarmClearedTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + alarmAcknowledgedTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + ackState: + description: > + Acknowledgement state of the alarm. Permitted values: * + UNACKNOWLEDGED * ACKNOWLEDGED. + type: string + enum: + - UNACKNOWLEDGED + - ACKNOWLEDGED + perceivedSeverity: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level indicates + that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a service + affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the detection + of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level indicates + that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the clearing + of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + eventType: + description: > + The enumeration EventType represents those types of events + that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of + this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is associated + with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is associated + with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated with an + equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + faultType: + description: > + Additional information to clarify the type of the fault. Valid + values applicable to specific Alarms are specified as "Alarm + definition identifier" values of the Alarm applicable to + Ve-Vnfm reference point. If the alarm is related to changes in + the state of virtualised resources due to NFVI operation and + maintenance, this attribute shall be set to + "NFVI_OAM_VIRTUALISED_RESOURCE_STATE _CHANGE". + type: string + probableCause: + description: > + Information about the probable cause of the fault. Valid + values applicable to specific Alarms are specified as + "Probable cause" values of the Alarm applicable to Ve-Vnfm + reference point. If the attribute "faultType" has the value + “NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE”, the permitted + values are: + - "NFVI_COMPONENT_MAINTENANCE": Maintenance of NFVI components, e.g. physical maintenance/repair, + hypervisor software updates, etc. + - "NFVI_COMPONENT_EVACUATION": Evacuation of physical hosts. + - "NFVI_COMPONENT_OPTIMIZATION": Operation and management of NFVI resources, e.g. to support energy + efficiency or resource usage optimization. + type: string + isRootCause: + description: | + The Boolean is a data type having two values (true and false). + type: boolean + correlatedAlarmIds: + description: | + List of identifiers of other alarms correlated to this fault. + type: array + items: + description: | + An identifier with the intention of being globally unique. + type: string + faultDetails: + description: > + Provides additional information about the fault. See notes 1 + and 2. Valid values applicable to specific Alarms are + specified as "Fault details" values of the Alarm applicable + to Ve-Vnfm reference point. + type: array + items: + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + objectInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualAlarm.Get.200: + description: > + 200 OK + + Shall be returned when information about an individual alarm read + successfully. The response body shall contain + + a representation of the individual alarm. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + ETag: + description: > + Used to provide the current entity-tag for the selected resource + representation. It can be sent in "200 OK", "201 Created" and "204 + No Content" responses. + style: simple + schema: + type: string + Last-Modified: + description: > + Used to provide a timestamp indicating the date and time at which + the server believes the selected resource representation was last + modified. It can be sent in "200 OK", "201 Created" and "204 No + Content" responses. + style: simple + schema: + type: string + format: date-time + content: + application/json: + schema: + description: > + The alarm data type encapsulates information about an alarm. + + If the attribute "faultType" has the value + "NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE", the following + provisions apply for the values of the attribute "faultDetails" + related to changes in the state of virtualised resources: + - One of the entries in the array shall provide information about the anticipated time of maintenance in the + following format: "anticipatedTime=$time", wherein "$time" shall be formatted as a "DateTime", as specified + in ETSI GS NFV-SOL 013. + - One of the entries in the array shall provide identification information about the affinity/anti-affinity group + defined in the VNFD that is associated to the affected virtualised resource indicated by "rootCauseFaultyResource" + in the following format: "affinityOrAntiAffinityGroupId=$group", wherein "$group" shall be equal to the + "affinityOrAntiAffinityGroupId" value in the corresponding "VduProfile" (for a VNFC/COMPUTE affected resource) + or "VirtualLinkProfile" for a VL/NETWORK affected resource) in the VNFD, which is mapped by the VNFM to the + virtualised resource group identifier in the virtualised resource change notification received by the VNFM from + the VIM. + + NOTE 1: For an alarm about upcoming impact due to NFVI operation + and maintenance (i.e. the attribute "faultType" + has the value "NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE"), the attribute "rootCauseFaultyResource" + indicates a resource to be impacted. Further information on the upcoming impact (e.g. group of impacted + resources, time of impact) is provided in the attribute "faultDetails". + NOTE 2: When alarms are due to upcoming NFVI operation and + maintenance (i.e. the attribute "faultType" has the + value "NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE"), the attribute "faultDetails" shall include information + about the anticipated time of the maintenance. See provisions under the present table. + type: object + required: + - id + - managedObjectId + - alarmRaisedTime + - ackState + - perceivedSeverity + - eventTime + - eventType + - probableCause + - isRootCause + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + managedObjectId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfcInstanceIds: + description: > + Identifiers of the affected VNFC instances. Each identifier + references the "id" attribute in a "VnfcInfo" structure. + Shall be present if the alarm affects at least one VNFC + instance. + type: array + items: + description: > + An identifier that is unique for the respective type within + a VNF instance, but may not be globally unique. + type: string + rootCauseFaultyResource: + description: > + This type represents the faulty virtual resources that have a + negative impact on a VNF. + type: object + required: + - faultyResource + - faultyResourceType + properties: + faultyResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available from + the VIM. + + * NOTE 1: The information about the VIM or CISM connection + referenced by the VIM connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service is a + Kubernetes® instance the resourceId shall be populated in + the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is allocated. + It shall be present for compute resources in the + scope of the CISM and shall be absent otherwise. + See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is managed + by a CISM and it shall be absent otherwise. + type: string + faultyResourceType: + description: > + The enumeration FaultyResourceType represents those types + of faulty resource. + type: string + enum: + - COMPUTE + - STORAGE + - NETWORK + alarmRaisedTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + alarmChangedTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + alarmClearedTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + alarmAcknowledgedTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + ackState: + description: > + Acknowledgement state of the alarm. Permitted values: * + UNACKNOWLEDGED * ACKNOWLEDGED. + type: string + enum: + - UNACKNOWLEDGED + - ACKNOWLEDGED + perceivedSeverity: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level indicates + that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a service + affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the detection + of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level indicates + that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the clearing + of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + eventType: + description: > + The enumeration EventType represents those types of events + that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of + this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is associated + with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is associated + with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated with an + equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + faultType: + description: > + Additional information to clarify the type of the fault. Valid + values applicable to specific Alarms are specified as "Alarm + definition identifier" values of the Alarm applicable to + Ve-Vnfm reference point. If the alarm is related to changes in + the state of virtualised resources due to NFVI operation and + maintenance, this attribute shall be set to + "NFVI_OAM_VIRTUALISED_RESOURCE_STATE _CHANGE". + type: string + probableCause: + description: > + Information about the probable cause of the fault. Valid + values applicable to specific Alarms are specified as + "Probable cause" values of the Alarm applicable to Ve-Vnfm + reference point. If the attribute "faultType" has the value + “NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE”, the permitted + values are: + - "NFVI_COMPONENT_MAINTENANCE": Maintenance of NFVI components, e.g. physical maintenance/repair, + hypervisor software updates, etc. + - "NFVI_COMPONENT_EVACUATION": Evacuation of physical hosts. + - "NFVI_COMPONENT_OPTIMIZATION": Operation and management of NFVI resources, e.g. to support energy + efficiency or resource usage optimization. + type: string + isRootCause: + description: | + The Boolean is a data type having two values (true and false). + type: boolean + correlatedAlarmIds: + description: | + List of identifiers of other alarms correlated to this fault. + type: array + items: + description: | + An identifier with the intention of being globally unique. + type: string + faultDetails: + description: > + Provides additional information about the fault. See notes 1 + and 2. Valid values applicable to specific Alarms are + specified as "Fault details" values of the Alarm applicable + to Ve-Vnfm reference point. + type: array + items: + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + objectInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualAlarm.Patch.200: + description: > + 200 OK + + Shall be returned when the request was accepted and completed. The + response body shall contain attribute + + modifications for an "Individual alarm" resource. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + ETag: + description: > + Used to provide the current entity-tag for the selected resource + representation. It can be sent in "200 OK", "201 Created" and "204 + No Content" responses. + style: simple + schema: + type: string + Last-Modified: + description: > + Used to provide a timestamp indicating the date and time at which + the server believes the selected resource representation was last + modified. It can be sent in "200 OK", "201 Created" and "204 No + Content" responses. + style: simple + schema: + type: string + format: date-time + content: + application/json: + schema: + description: > + This type represents attribute modifications for an "Individual + alarm" resource, i.e. modifications to a resource representation + based on the "Alarm" data type. The attributes of "Alarm" that can + be modified are included in the "AlarmModifications" data type. + type: object + required: + - ackState + properties: + ackState: + description: > + New value of the "ackState" attribute in "Alarm". Permitted + values: * ACKNOWLEDGED * UNACKNOWLEDGED + type: string + enum: + - ACKNOWLEDGED + - UNACKNOWLEDGED + IndividualAlarm.Patch.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the "Individual alarm" + resource. + Typically, this is due to the fact that the alarm is + already in the state that is requested to be set (such + as trying to acknowledge an already-acknowledged + alarm). + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualAlarmEscalate.Post.204: + description: > + 204 No Content + + Shall be returned when the VNFM has received the proposed "escalated + perceived severity" value successfully. + + The response body shall be empty. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + content: {} + Subscriptions.Get.200: + description: > + 200 OK + + Shall be returned when the list of subscriptions has been queried + successfully. + + The response body shall contain the representations of all active + subscriptions of the functional block that + + invokes the method. If the "filter" URI parameter was supplied in the + request, the data in the response body + + shall have been transformed according to the rules specified in clause + 5.2.2 of ETSI GS NFV-SOL 013. + + If the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 + of ETSI GS NFV-SOL 013 for this resource, + + inclusion of the Link HTTP header in this response shall follow the + provisions in clause 5.4.2.3 of + + ETSI GS NFV-SOL 013. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + This type represents a subscription related to notifications about + VNF faults. + type: object + required: + - id + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: "This type represents a subscription filter related to notifications about VNF faults.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdIds + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId values + listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, from + one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tAlarmNotification -\tAlarmClearedNotification -\tAlarmListRebuiltNotification See note.\n" + type: array + items: + type: string + enum: + - AlarmNotification + - AlarmClearedNotification + - AlarmListRebuiltNotification + faultyResourceTypes: + description: > + Match VNF alarms with a faulty resource type listed in + this attribute. + type: array + items: + description: > + The enumeration FaultyResourceType represents those + types of faulty resource. + type: string + enum: + - COMPUTE + - STORAGE + - NETWORK + perceivedSeverities: + description: > + Match VNF alarms with a perceived severity listed in this + attribute. + type: array + items: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level + indicates that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a + service affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the + existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the + detection of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level + indicates that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the + clearing of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTypes: + description: > + Match VNF alarms with an event type listed in this + attribute. + type: array + items: + description: > + The enumeration EventType represents those types of + events that trigger an alarm. * COMMUNICATIONS_ALARM: An + alarm of this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is + associated with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is + associated with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated + with an equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + probableCauses: + description: > + Match VNF alarms with a probable cause listed in this + attribute. + type: array + items: + type: string + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + fmConnection: + description: > + An access information and interface information to monitor the + FM of VNF instance by the VNFM. This can include for instance + certain interface endpoint URI together with necessary + credentials to access it. + type: array + items: + description: "The MonitoringConnection shall follow the indications. * NOTE:\tThe VNFM can be made aware of monitoring connection information, including their identifiers to \n be used by configuration means outside the scope of the present document (e.g. using relevant NFV-MANO management \n APIs as defined in ETSI GS NFV-SOL 009). \n" + type: object + required: + - id + - monitoringType + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + monitoringType: + description: "Type of monitoring way. VALUES: \n •\tVIM_CISM\n •\tEXTERNAL\n •\tPAAS\n" + type: string + enum: + - VIM_CISM + - EXTERNAL + - PAAS + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being globally + unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: | + A string defined in IETF RFC 8259. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + Subscriptions.Post.201: + description: > + 201 CREATED + + The subscription was created successfully. The response body shall + contain a representation of the created + + subscription resource. The HTTP response shall include a "Location:" + HTTP header that points to the created + + subscription resource. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + content: + application/json: + schema: + description: > + This type represents a subscription related to notifications about + VNF faults. + type: object + required: + - id + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: "This type represents a subscription filter related to notifications about VNF faults.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdIds + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId values + listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, from + one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tAlarmNotification -\tAlarmClearedNotification -\tAlarmListRebuiltNotification See note.\n" + type: array + items: + type: string + enum: + - AlarmNotification + - AlarmClearedNotification + - AlarmListRebuiltNotification + faultyResourceTypes: + description: > + Match VNF alarms with a faulty resource type listed in + this attribute. + type: array + items: + description: > + The enumeration FaultyResourceType represents those + types of faulty resource. + type: string + enum: + - COMPUTE + - STORAGE + - NETWORK + perceivedSeverities: + description: > + Match VNF alarms with a perceived severity listed in this + attribute. + type: array + items: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level + indicates that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a + service affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the + existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the + detection of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level + indicates that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the + clearing of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTypes: + description: > + Match VNF alarms with an event type listed in this + attribute. + type: array + items: + description: > + The enumeration EventType represents those types of + events that trigger an alarm. * COMMUNICATIONS_ALARM: An + alarm of this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is + associated with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is + associated with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated + with an equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + probableCauses: + description: > + Match VNF alarms with a probable cause listed in this + attribute. + type: array + items: + type: string + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + fmConnection: + description: > + An access information and interface information to monitor the + FM of VNF instance by the VNFM. This can include for instance + certain interface endpoint URI together with necessary + credentials to access it. + type: array + items: + description: "The MonitoringConnection shall follow the indications. * NOTE:\tThe VNFM can be made aware of monitoring connection information, including their identifiers to \n be used by configuration means outside the scope of the present document (e.g. using relevant NFV-MANO management \n APIs as defined in ETSI GS NFV-SOL 009). \n" + type: object + required: + - id + - monitoringType + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + monitoringType: + description: "Type of monitoring way. VALUES: \n •\tVIM_CISM\n •\tEXTERNAL\n •\tPAAS\n" + type: string + enum: + - VIM_CISM + - EXTERNAL + - PAAS + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being globally + unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: | + A string defined in IETF RFC 8259. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + Subscriptions.Post.422: + description: > + 422 Unprocessable Content + + + Shall be returned upon the following error: The content type of the + message content is supported + + and the message content of a request contains syntactically correct data + but the data cannot be processed. + + The general cause for this error and its handling is specified in clause + 6.4 of ETSI GS NFV-SOL 013, + + including rules for the presence of the response body. + + Specifically in case of this resource, the response code 422 shall also + be returned if the VNFM has tested + + the Notification endpoint as described in clause 7.4.7.3.2 and the test + has failed. + + In this case, the "detail" attribute in the "ProblemDetails" structure + shall convey more information + + about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: Version of the API used in the response. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualSubscription.Get.200: + description: > + 200 OK + + Shall be returned when information about an individual subscription has + been read successfully. + + The response body shall contain a representation of the "Individual + subscription" resource. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + This type represents a subscription related to notifications about + VNF faults. + type: object + required: + - id + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: "This type represents a subscription filter related to notifications about VNF faults.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdIds + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId values + listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, from + one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tAlarmNotification -\tAlarmClearedNotification -\tAlarmListRebuiltNotification See note.\n" + type: array + items: + type: string + enum: + - AlarmNotification + - AlarmClearedNotification + - AlarmListRebuiltNotification + faultyResourceTypes: + description: > + Match VNF alarms with a faulty resource type listed in + this attribute. + type: array + items: + description: > + The enumeration FaultyResourceType represents those + types of faulty resource. + type: string + enum: + - COMPUTE + - STORAGE + - NETWORK + perceivedSeverities: + description: > + Match VNF alarms with a perceived severity listed in this + attribute. + type: array + items: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level + indicates that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a + service affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the + existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the + detection of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level + indicates that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the + clearing of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTypes: + description: > + Match VNF alarms with an event type listed in this + attribute. + type: array + items: + description: > + The enumeration EventType represents those types of + events that trigger an alarm. * COMMUNICATIONS_ALARM: An + alarm of this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is + associated with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is + associated with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated + with an equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + probableCauses: + description: > + Match VNF alarms with a probable cause listed in this + attribute. + type: array + items: + type: string + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + fmConnection: + description: > + An access information and interface information to monitor the + FM of VNF instance by the VNFM. This can include for instance + certain interface endpoint URI together with necessary + credentials to access it. + type: array + items: + description: "The MonitoringConnection shall follow the indications. * NOTE:\tThe VNFM can be made aware of monitoring connection information, including their identifiers to \n be used by configuration means outside the scope of the present document (e.g. using relevant NFV-MANO management \n APIs as defined in ETSI GS NFV-SOL 009). \n" + type: object + required: + - id + - monitoringType + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + monitoringType: + description: "Type of monitoring way. VALUES: \n •\tVIM_CISM\n •\tEXTERNAL\n •\tPAAS\n" + type: string + enum: + - VIM_CISM + - EXTERNAL + - PAAS + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being globally + unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: | + A string defined in IETF RFC 8259. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualSubscription.Delete.204: + description: > + 204 NO CONTENT + + Shall be returned when the "Individual subscription" resource has been + deleted successfully. + + The response body shall be empty. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + content: {} + diff --git a/v5.3.1/SOL002-VNFFaultManagementNotification-API.json b/v5.3.1/SOL002-VNFFaultManagementNotification-API.json new file mode 100644 index 00000000..b6c57620 --- /dev/null +++ b/v5.3.1/SOL002-VNFFaultManagementNotification-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL002 - VNF Fault Management Notification interface","description":"SOL002 - VNF Fault Management Notification interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nhttps://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"1.14.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 002 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/05.03.01_60/gs_NFV-SOL002v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/callback/v1"},{"url":"https://127.0.0.1/callback/v1"}],"paths":{"/URI_is_provided_by_the_client_when_creating_the_subscription-AlarmNotification":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method allows the API producer to test the notification endpoint that is provided by the API consumer,\ne.g. during subscription. See clause 7.4.7.3.2.\n","responses":{"204":{"$ref":"#/components/responses/VNFFMNotification.Get.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"The POST method notifies a VNF alarm or that the alarm list has been rebuilt. The API consumer shall have\npreviously created an \"Individual subscription\" resource with a matching filter. See clause 7.4.7.3.1.\n","parameters":[{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/AlarmNotification"},"responses":{"204":{"$ref":"#/components/responses/VNFFMNotification.Post.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/URI_is_provided_by_the_client_when_creating_the_subscription-AlarmClearedNotification":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method allows the API producer to test the notification endpoint that is provided by the API consumer,\ne.g. during subscription. See clause 7.4.7.3.2.\n","responses":{"204":{"$ref":"#/components/responses/VNFFMNotification.Get.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"The POST method notifies a VNF alarm or that the alarm list has been rebuilt. The API consumer shall have\npreviously created an \"Individual subscription\" resource with a matching filter. See clause 7.4.7.3.1.\n","parameters":[{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/AlarmClearedNotification"},"responses":{"204":{"$ref":"#/components/responses/VNFFMNotification.Post.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/URI_is_provided_by_the_client_when_creating_the_subscription-AlarmListRebuiltNotification":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method allows the API producer to test the notification endpoint that is provided by the API consumer,\ne.g. during subscription. See clause 7.4.7.3.2.\n","responses":{"204":{"$ref":"#/components/responses/VNFFMNotification.Get.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"The POST method notifies a VNF alarm or that the alarm list has been rebuilt. The API consumer shall have\npreviously created an \"Individual subscription\" resource with a matching filter. See clause 7.4.7.3.1.\n","parameters":[{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/AlarmListRebuiltNotification"},"responses":{"204":{"$ref":"#/components/responses/VNFFMNotification.Post.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"requestBodies":{"AlarmNotification":{"description":"Information of a VNF alarm.\n","content":{"application/json":{"schema":{"description":"This type represents an alarm notification about VNF faults. This notification shall be triggered by the VNFM when: * An alarm has been created. * An alarm has been updated, e.g. if the severity of the alarm has changed.\n","type":"object","required":["id","notificationType","subscriptionId","timeStamp","alarm","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"AlarmNotification\" for this notification type.\n","type":"string","enum":["AlarmNotification"]},"subscriptionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"alarm":{"description":"The alarm data type encapsulates information about an alarm.\nIf the attribute \"faultType\" has the value \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE\", the following provisions apply for the values of the attribute \"faultDetails\" related to changes in the state of virtualised resources: - One of the entries in the array shall provide information about the anticipated time of maintenance in the\n following format: \"anticipatedTime=$time\", wherein \"$time\" shall be formatted as a \"DateTime\", as specified\n in ETSI GS NFV-SOL 013.\n - One of the entries in the array shall provide identification information about the affinity/anti-affinity group\n defined in the VNFD that is associated to the affected virtualised resource indicated by \"rootCauseFaultyResource\" \n in the following format: \"affinityOrAntiAffinityGroupId=$group\", wherein \"$group\" shall be equal to the \n \"affinityOrAntiAffinityGroupId\" value in the corresponding \"VduProfile\" (for a VNFC/COMPUTE affected resource) \n or \"VirtualLinkProfile\" for a VL/NETWORK affected resource) in the VNFD, which is mapped by the VNFM to the \n virtualised resource group identifier in the virtualised resource change notification received by the VNFM from \n the VIM.\n\nNOTE 1: For an alarm about upcoming impact due to NFVI operation and maintenance (i.e. the attribute \"faultType\" has the value \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE\"), the attribute \"rootCauseFaultyResource\" \n indicates a resource to be impacted. Further information on the upcoming impact (e.g. group of impacted \n resources, time of impact) is provided in the attribute \"faultDetails\".\nNOTE 2: When alarms are due to upcoming NFVI operation and maintenance (i.e. the attribute \"faultType\" has the value \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE\"), the attribute \"faultDetails\" shall include information \n about the anticipated time of the maintenance. See provisions under the present table.\n","type":"object","required":["id","managedObjectId","alarmRaisedTime","ackState","perceivedSeverity","eventTime","eventType","probableCause","isRootCause","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"managedObjectId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcInstanceIds":{"description":"Identifiers of the affected VNFC instances. Each identifier references the \"id\" attribute in a \"VnfcInfo\" structure. Shall be present if the alarm affects at least one VNFC instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"rootCauseFaultyResource":{"description":"This type represents the faulty virtual resources that have a negative impact on a VNF.\n","type":"object","required":["faultyResource","faultyResourceType"],"properties":{"faultyResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"faultyResourceType":{"description":"The enumeration FaultyResourceType represents those types of faulty resource.\n","type":"string","enum":["COMPUTE","STORAGE","NETWORK"]}}},"alarmRaisedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"alarmChangedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"alarmClearedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"alarmAcknowledgedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"ackState":{"description":"Acknowledgement state of the alarm. Permitted values: * UNACKNOWLEDGED * ACKNOWLEDGED.\n","type":"string","enum":["UNACKNOWLEDGED","ACKNOWLEDGED"]},"perceivedSeverity":{"description":"Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n","type":"string","enum":["CRITICAL","MAJOR","MINOR","WARNING","INDETERMINATE","CLEARED"]},"eventTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"eventType":{"description":"The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment fault (ITU-T Recommendation X.733).\n","type":"string","enum":["COMMUNICATIONS_ALARM","PROCESSING_ERROR_ALARM","ENVIRONMENTAL_ALARM","QOS_ALARM","EQUIPMENT_ALARM"]},"faultType":{"description":"Additional information to clarify the type of the fault. Valid values applicable to specific Alarms are specified as \"Alarm definition identifier\" values of the Alarm applicable to Ve-Vnfm reference point. If the alarm is related to changes in the state of virtualised resources due to NFVI operation and maintenance, this attribute shall be set to \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE _CHANGE\".\n","type":"string"},"probableCause":{"description":"Information about the probable cause of the fault. Valid values applicable to specific Alarms are specified as \"Probable cause\" values of the Alarm applicable to Ve-Vnfm reference point. If the attribute \"faultType\" has the value “NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE”, the permitted values are: - \"NFVI_COMPONENT_MAINTENANCE\": Maintenance of NFVI components, e.g. physical maintenance/repair, \n hypervisor software updates, etc.\n - \"NFVI_COMPONENT_EVACUATION\": Evacuation of physical hosts.\n - \"NFVI_COMPONENT_OPTIMIZATION\": Operation and management of NFVI resources, e.g. to support energy\n efficiency or resource usage optimization.\n","type":"string"},"isRootCause":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"correlatedAlarmIds":{"description":"List of identifiers of other alarms correlated to this fault.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"faultDetails":{"description":"Provides additional information about the fault. See notes 1 and 2. Valid values applicable to specific Alarms are specified as \"Fault details\" values of the Alarm applicable to Ve-Vnfm reference point.\n","type":"array","items":{"type":"string"}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"objectInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}},"_links":{"description":"Links to resources related to this notification.\n","type":"object","required":["subscription"],"properties":{"subscription":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true},"AlarmClearedNotification":{"description":"Information of the clearance of a VNF alarm.\n","content":{"application/json":{"schema":{"description":"This type represents an alarm cleared notification about VNF faults. The notification shall be triggered by the VNFM when an alarm has been cleared.\n","type":"object","required":["id","notificationType","subscriptionId","timeStamp","alarmId","alarmClearedTime","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"AlarmClearedNotification\" for this notification type.\n","type":"string","enum":["AlarmClearedNotification"]},"subscriptionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"alarmId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"alarmClearedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"_links":{"description":"Links to resources related to this notification.\n","type":"object","required":["subscription","alarm"],"properties":{"subscription":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"alarm":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true},"AlarmListRebuiltNotification":{"description":"Information that the alarm list has been rebuilt by the VNFM.\n","content":{"application/json":{"schema":{"description":"This type represents a notification that the alarm list has been rebuilt, e.g. if the VNFM detects its storage holding the alarm list is corrupted. The notification shall be triggered by the VNFM when the alarm list has been rebuilt, e.g. because the VNFM has detected that its storage holding the alarm list was corrupted.\n","type":"object","required":["id","notificationType","subscriptionId","timeStamp","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"AlarmListRebuiltNotification\" for this notification type.\n","type":"string","enum":["AlarmListRebuiltNotification"]},"subscriptionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"_links":{"description":"Links to resources related to this notification.\n","type":"object","required":["subscription","alarms"],"properties":{"subscription":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"alarms":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true}},"responses":{"VNFFMNotification.Get.204":{"description":"204 NO CONTENT\nShall be returned to indicate the notification endpoint has been tested successfully. The response body\nshall be empty.\n","headers":{"Version":{"description":"Version of the API used in the response.\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{}},"VNFFMNotification.Post.204":{"description":"204 NO CONTENT\nShall be returned when the notification has been delivered successfully. The response body shall be empty.\n","headers":{"Version":{"description":"Version of the API used in the response.\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{}}}}} diff --git a/v5.3.1/SOL002-VNFFaultManagementNotification-API.yaml b/v5.3.1/SOL002-VNFFaultManagementNotification-API.yaml new file mode 100644 index 00000000..a76a472f --- /dev/null +++ b/v5.3.1/SOL002-VNFFaultManagementNotification-API.yaml @@ -0,0 +1,4899 @@ +openapi: 3.0.2 +info: + title: SOL002 - VNF Fault Management Notification interface + description: | + SOL002 - VNF Fault Management Notification interface + + 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. + + https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '1.14.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 002 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/05.03.01_60/gs_NFV-SOL002v050301p.pdf +servers: + - url: 'http://127.0.0.1/callback/v1' + - url: 'https://127.0.0.1/callback/v1' +paths: + /URI_is_provided_by_the_client_when_creating_the_subscription-AlarmNotification: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The GET method allows the API producer to test the notification endpoint + that is provided by the API consumer, + + e.g. during subscription. See clause 7.4.7.3.2. + responses: + '204': + $ref: '#/components/responses/VNFFMNotification.Get.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + The POST method notifies a VNF alarm or that the alarm list has been + rebuilt. The API consumer shall have + + previously created an "Individual subscription" resource with a matching + filter. See clause 7.4.7.3.1. + parameters: + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/AlarmNotification' + responses: + '204': + $ref: '#/components/responses/VNFFMNotification.Post.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /URI_is_provided_by_the_client_when_creating_the_subscription-AlarmClearedNotification: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The GET method allows the API producer to test the notification endpoint + that is provided by the API consumer, + + e.g. during subscription. See clause 7.4.7.3.2. + responses: + '204': + $ref: '#/components/responses/VNFFMNotification.Get.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + The POST method notifies a VNF alarm or that the alarm list has been + rebuilt. The API consumer shall have + + previously created an "Individual subscription" resource with a matching + filter. See clause 7.4.7.3.1. + parameters: + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/AlarmClearedNotification' + responses: + '204': + $ref: '#/components/responses/VNFFMNotification.Post.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /URI_is_provided_by_the_client_when_creating_the_subscription-AlarmListRebuiltNotification: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The GET method allows the API producer to test the notification endpoint + that is provided by the API consumer, + + e.g. during subscription. See clause 7.4.7.3.2. + responses: + '204': + $ref: '#/components/responses/VNFFMNotification.Get.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + The POST method notifies a VNF alarm or that the alarm list has been + rebuilt. The API consumer shall have + + previously created an "Individual subscription" resource with a matching + filter. See clause 7.4.7.3.1. + parameters: + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/AlarmListRebuiltNotification' + responses: + '204': + $ref: '#/components/responses/VNFFMNotification.Post.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + requestBodies: + AlarmNotification: + description: | + Information of a VNF alarm. + content: + application/json: + schema: + description: > + This type represents an alarm notification about VNF faults. This + notification shall be triggered by the VNFM when: * An alarm has + been created. * An alarm has been updated, e.g. if the severity of + the alarm has + changed. + type: object + required: + - id + - notificationType + - subscriptionId + - timeStamp + - alarm + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall be + set to "AlarmNotification" for this notification type. + type: string + enum: + - AlarmNotification + subscriptionId: + description: | + An identifier with the intention of being globally unique. + type: string + timeStamp: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + alarm: + description: > + The alarm data type encapsulates information about an alarm. + + If the attribute "faultType" has the value + "NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE", the following + provisions apply for the values of the attribute + "faultDetails" related to changes in the state of virtualised + resources: + - One of the entries in the array shall provide information about the anticipated time of maintenance in the + following format: "anticipatedTime=$time", wherein "$time" shall be formatted as a "DateTime", as specified + in ETSI GS NFV-SOL 013. + - One of the entries in the array shall provide identification information about the affinity/anti-affinity group + defined in the VNFD that is associated to the affected virtualised resource indicated by "rootCauseFaultyResource" + in the following format: "affinityOrAntiAffinityGroupId=$group", wherein "$group" shall be equal to the + "affinityOrAntiAffinityGroupId" value in the corresponding "VduProfile" (for a VNFC/COMPUTE affected resource) + or "VirtualLinkProfile" for a VL/NETWORK affected resource) in the VNFD, which is mapped by the VNFM to the + virtualised resource group identifier in the virtualised resource change notification received by the VNFM from + the VIM. + + NOTE 1: For an alarm about upcoming impact due to NFVI + operation and maintenance (i.e. the attribute "faultType" + has the value "NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE"), the attribute "rootCauseFaultyResource" + indicates a resource to be impacted. Further information on the upcoming impact (e.g. group of impacted + resources, time of impact) is provided in the attribute "faultDetails". + NOTE 2: When alarms are due to upcoming NFVI operation and + maintenance (i.e. the attribute "faultType" has the + value "NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE"), the attribute "faultDetails" shall include information + about the anticipated time of the maintenance. See provisions under the present table. + type: object + required: + - id + - managedObjectId + - alarmRaisedTime + - ackState + - perceivedSeverity + - eventTime + - eventType + - probableCause + - isRootCause + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + managedObjectId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfcInstanceIds: + description: > + Identifiers of the affected VNFC instances. Each + identifier references the "id" attribute in a "VnfcInfo" + structure. Shall be present if the alarm affects at least + one VNFC instance. + type: array + items: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + rootCauseFaultyResource: + description: > + This type represents the faulty virtual resources that + have a negative impact on a VNF. + type: object + required: + - faultyResource + - faultyResourceType + properties: + faultyResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service is + a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the CISM + and shall be absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + faultyResourceType: + description: > + The enumeration FaultyResourceType represents those + types of faulty resource. + type: string + enum: + - COMPUTE + - STORAGE + - NETWORK + alarmRaisedTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + alarmChangedTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + alarmClearedTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + alarmAcknowledgedTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + ackState: + description: > + Acknowledgement state of the alarm. Permitted values: * + UNACKNOWLEDGED * ACKNOWLEDGED. + type: string + enum: + - UNACKNOWLEDGED + - ACKNOWLEDGED + perceivedSeverity: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level + indicates that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a service + affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the existence + of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the + detection of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level + indicates that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the + clearing of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + eventType: + description: > + The enumeration EventType represents those types of events + that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of + this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is + associated with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is associated + with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated + with an equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + faultType: + description: > + Additional information to clarify the type of the fault. + Valid values applicable to specific Alarms are specified + as "Alarm definition identifier" values of the Alarm + applicable to Ve-Vnfm reference point. If the alarm is + related to changes in the state of virtualised resources + due to NFVI operation and maintenance, this attribute + shall be set to "NFVI_OAM_VIRTUALISED_RESOURCE_STATE + _CHANGE". + type: string + probableCause: + description: > + Information about the probable cause of the fault. Valid + values applicable to specific Alarms are specified as + "Probable cause" values of the Alarm applicable to + Ve-Vnfm reference point. If the attribute "faultType" has + the value “NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE”, + the permitted values are: + - "NFVI_COMPONENT_MAINTENANCE": Maintenance of NFVI components, e.g. physical maintenance/repair, + hypervisor software updates, etc. + - "NFVI_COMPONENT_EVACUATION": Evacuation of physical hosts. + - "NFVI_COMPONENT_OPTIMIZATION": Operation and management of NFVI resources, e.g. to support energy + efficiency or resource usage optimization. + type: string + isRootCause: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + correlatedAlarmIds: + description: > + List of identifiers of other alarms correlated to this + fault. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + faultDetails: + description: > + Provides additional information about the fault. See notes + 1 and 2. Valid values applicable to specific Alarms are + specified as "Fault details" values of the Alarm + applicable to Ve-Vnfm reference point. + type: array + items: + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + objectInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + _links: + description: | + Links to resources related to this notification. + type: object + required: + - subscription + properties: + subscription: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + AlarmClearedNotification: + description: | + Information of the clearance of a VNF alarm. + content: + application/json: + schema: + description: > + This type represents an alarm cleared notification about VNF + faults. The notification shall be triggered by the VNFM when an + alarm has been cleared. + type: object + required: + - id + - notificationType + - subscriptionId + - timeStamp + - alarmId + - alarmClearedTime + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall be + set to "AlarmClearedNotification" for this notification type. + type: string + enum: + - AlarmClearedNotification + subscriptionId: + description: | + An identifier with the intention of being globally unique. + type: string + timeStamp: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + alarmId: + description: | + An identifier with the intention of being globally unique. + type: string + alarmClearedTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + _links: + description: | + Links to resources related to this notification. + type: object + required: + - subscription + - alarm + properties: + subscription: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + alarm: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + AlarmListRebuiltNotification: + description: | + Information that the alarm list has been rebuilt by the VNFM. + content: + application/json: + schema: + description: > + This type represents a notification that the alarm list has been + rebuilt, e.g. if the VNFM detects its storage holding the alarm + list is corrupted. The notification shall be triggered by the VNFM + when the alarm list has been rebuilt, e.g. because the VNFM has + detected that its storage holding the alarm list was corrupted. + type: object + required: + - id + - notificationType + - subscriptionId + - timeStamp + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall be + set to "AlarmListRebuiltNotification" for this notification + type. + type: string + enum: + - AlarmListRebuiltNotification + subscriptionId: + description: | + An identifier with the intention of being globally unique. + type: string + timeStamp: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + _links: + description: | + Links to resources related to this notification. + type: object + required: + - subscription + - alarms + properties: + subscription: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + alarms: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + responses: + VNFFMNotification.Get.204: + description: > + 204 NO CONTENT + + Shall be returned to indicate the notification endpoint has been tested + successfully. The response body + + shall be empty. + headers: + Version: + description: | + Version of the API used in the response. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + content: {} + VNFFMNotification.Post.204: + description: > + 204 NO CONTENT + + Shall be returned when the notification has been delivered successfully. + The response body shall be empty. + headers: + Version: + description: | + Version of the API used in the response. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + content: {} + diff --git a/v5.3.1/SOL002-VNFIndicator-API.json b/v5.3.1/SOL002-VNFIndicator-API.json new file mode 100644 index 00000000..a9505874 --- /dev/null +++ b/v5.3.1/SOL002-VNFIndicator-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL002 - VNF Indicator interface","description":"SOL002 - VNF Indicator interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"1.13.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 002 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/05.03.01_60/gs_NFV-SOL002v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/vnfind/v1"},{"url":"https://127.0.0.1/vnfind/v1"}],"paths":{"/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/indicators":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method queries multiple VNF indicators. See clause 8.4.2.3.2.\n","parameters":[{"$ref":"#/components/parameters/filter_indicators"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [6] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/Indicators.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/indicators/{vnfInstanceId}":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method queries multiple VNF indicators related to a VNF instance. See clause 8.4.3.3.2.\n","parameters":[{"$ref":""},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [6] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/VnfIndicators.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/indicators/{vnfInstanceId}/{indicatorId}":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"},{"$ref":"#/components/parameters/IndicatorId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method reads a VNF indicator. See clause 8.4.4.3.2.\n","responses":{"200":{"$ref":"#/components/responses/VnfIndividualIndicator.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/subscriptions":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method queries the list of active subscriptions of the functional block that invokes the method.\nIt can be used e.g. for resynchronization after error situations. See clause 8.4.5.3.2.\n","parameters":[{"$ref":"#/components/parameters/filter_subscriptions"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [6] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/VnfIndicatorSubscriptions.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"The POST method creates a new subscription. See clause 8.4.5.3.1.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/VnfIndicatorSubscriptionRequest"},"responses":{"201":{"$ref":"#/components/responses/VnfIndicatorSubscription.Post.201"},"303":{"description":"303 See Other\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/VnfIndicatorSubscription.Post.422"},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/subscriptions/{subscriptionId}":{"parameters":[{"$ref":"#/components/parameters/SubscriptionId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method reads an individual subscription. See clause 8.4.6.3.2.\n","responses":{"200":{"$ref":"#/components/responses/VnfIndicatorSubscription.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"The DELETE method terminates an individual subscription. See clause 8.4.6.3.5.\n","responses":{"204":{"$ref":"#/components/responses/VnfIndicatorSubscription.Delete.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"parameters":{"filter_subscriptions":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013. The EM shall and the VNF may support receiving this parameter as part of the URI query string. The VNFM may supply this parameter. All attribute names that appear in the VnfIndicatorSubscription data type and in data types referenced from it shall be supported in the filter expression. If receiving, this parameter is not supported, a 400 Bad Request response shall be returned (see table 8.4.5.3.2-2).\n","in":"query","required":false,"schema":{"type":"string"}},"filter_vnf_indicators_related_to_vnf_instance":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013. The API producer shall support receiving this parameter as part of the URI query string. The VNFM may supply this parameter. All attribute names that appear in the VnfIndicator data type and in data types referenced from it shall be supported by the API producer in the filter expression.\n","in":"query","required":false,"schema":{"type":"string"}},"filter_indicators":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013. The API producer shall support receiving this parameter as part of the URI query string. The VNFM may supply this parameter. All attribute names that appear in the VnfIndicator data type and in data types referenced from it shall be supported by the API producer in the filter expression.\n","in":"query","required":false,"schema":{"type":"string"}},"VnfInstanceId":{"name":"vnfInstanceId","in":"path","description":"Service Unavailable.\nIdentifier of the VNF instance to which the VNF indicators applies.\nNOTE: This identifier can be retrieved from the resource referenced by the \"Location\" HTTP header in the\nresponse to a POST request creating a new VNF instance resource. It can also be retrieved from the \"id\"\nattribute in the message content of that response.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"IndicatorId":{"name":"indicatorId","in":"path","description":"Identifier of the VNF indicator.\nNOTE: This identifier can be retrieved from the resource referenced by the message content in the\nresponse to a POST request creating a new \"Individual VNF instance\" resource.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"SubscriptionId":{"name":"subscriptionId","in":"path","description":"Identifier of this subscription. NOTE:\nThis identifier can be retrieved from the resource referenced by the \"Location\" HTTP header\nin the response to a POST request creating a new subscription resource. It can also be retrieved\nfrom the \"id\" attribute in the message content of that response.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}}},"requestBodies":{"VnfIndicatorSubscriptionRequest":{"description":"Details of the subscription to be created.","content":{"application/json":{"schema":{"description":"This type represents a subscription request related to VNF indicator value change notifications.\n","type":"object","required":["callbackUri"],"properties":{"filter":{"description":"This type represents a subscription filter for notifications related to VNF indicators.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdIds"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tVnfIndicatorValueChangeNotification -\tSupportedIndicatorsChangeNotification See note.\n","type":"string","enum":["VnfIndicatorValueChangeNotification","SupportedIndicatorsChangeNotification"]},"indicatorIds":{"description":"Match particular VNF indicator identifiers.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE 1 : The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between\n subscriptions. The value of clientPassword should be generated by a random process.\n* NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT which uses mutual authentication based on X.509 certificates, this mode which uses client password to authenticate may be used in the access token request\n toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations\n (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details.\n* NOTE 3: The following values that were included up to version 3.4.1 of the present document have been removed: \"BASIC\" (to signal the use of the basic HTTP authentication) has been removed because it is insecure.\n \"TLS_CERT\" to signal an alternative non-token based authorization method using TLS certificates has been\n removed because the method is no longer supported.\n* NOTE 4: The client certificate is established by means outside the scope of the present document.\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values (see note 3): * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use\n an OAuth 2.0 token, obtained using the client\n credentials grant type after authenticating\n using client identifier and client password\n towards the token endpoint.\n* OAUTH2_CLIENT_CERT: In every HTTP request to the notification endpoint, use an\n OAuth 2.0 token, obtained using the client\n credentials grant type after mutually\n authenticating using client identifier and X.509\n certificates towards the token endpoint.\n","type":"array","items":{"type":"string","enum":["OAUTH2_CLIENT_CREDENTIALS","OAUTH2_CLIENT_CERT"]}},"paramsOauth2ClientCert":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CERT.\nShall be present if authType is \"OAUTH2_CLIENT_CERT\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\n","type":"object","required":["clientId","certificateRef","tokenEndpoint"],"properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint.\n","type":"string"},"certificateRef":{"description":"Fingerprint of the client certificate. The hash function shall use SHA256 or higher. See note 4.\n","type":"string","required":["type","value"],"properties":{"type":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"value":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS.\nShall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\nSee note 2.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"clientPassword":{"description":"Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true}},"responses":{"Indicators.Get.200":{"description":"200 OK\nShall be returned when information about zero or more VNF indicators was queried successfully.\nThe response body shall contain in an array the representations of all VNF indicators that match the\nattribute-based filtering parameters, i.e. zero or more representations of VNF indicators as defined\nin clause 8.5.2.2. If the \"filter\" URI parameter was supplied in the request, the data in the response\nbody shall have been transformed according to the rules specified in clause 5.2.2 of ETSI GS NFV-SOL 013.\nIf the EM/VNF supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013for this\nresource, inclusion of the Link HTTP header in this response shall follow the provisions in clause 5.4.2.3\nof ETSI GS NFV-SOL 013.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a VNF indicator value.\nNOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n","type":"object","required":["id","value","vnfInstanceId","_links"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Human readable name of the indicator. Shall be present if defined in the VNFD.\n","type":"string"},"value":{"description":"Provides the value of the indicator. The value format is defined in the VNFD. See note.\n","type":"object"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcInstanceIds":{"description":"The vnfcInstanceIds attribute is optionally present. If present, it contains the list of identifiers of VNFC instances which provide the indicator value(s).\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self","vnfInstance"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"VnfIndicators.Get.200":{"description":"200 OK\nShall be returned when information about zero or more VNF indicators was queried successfully.\nThe response body shall contain in an array the representations of all VNF indicators that are related\nto the particular VNF instance and that match the attribute filter., i.e. zero or more representations\nof VNF indicators as defined in clause 8.5.2.2. If the \"filter\" URI parameter was supplied in the request,\nthe data in the response body shall have been transformed according to the rules specified in clause\n5.2.2 of ETSI GS NFV-SOL 013. If the EM/VMF supports alternative 2 (paging) according to clause 5.4.2.1 of\nETSI GS NFV-SOL 013 for this resource, inclusion of the Link HTTP header in this response shall follow the\nprovisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a VNF indicator value.\nNOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n","type":"object","required":["id","value","vnfInstanceId","_links"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Human readable name of the indicator. Shall be present if defined in the VNFD.\n","type":"string"},"value":{"description":"Provides the value of the indicator. The value format is defined in the VNFD. See note.\n","type":"object"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcInstanceIds":{"description":"The vnfcInstanceIds attribute is optionally present. If present, it contains the list of identifiers of VNFC instances which provide the indicator value(s).\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self","vnfInstance"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"VnfIndividualIndicator.Get.200":{"description":"200 OK\nShall be returned when the VNF indicator has been read successfully. The response body shall contain the\nrepresentation of the VNF indicator.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a VNF indicator value.\nNOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n","type":"object","required":["id","value","vnfInstanceId","_links"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Human readable name of the indicator. Shall be present if defined in the VNFD.\n","type":"string"},"value":{"description":"Provides the value of the indicator. The value format is defined in the VNFD. See note.\n","type":"object"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcInstanceIds":{"description":"The vnfcInstanceIds attribute is optionally present. If present, it contains the list of identifiers of VNFC instances which provide the indicator value(s).\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self","vnfInstance"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"VnfIndicatorSubscriptions.Get.200":{"description":"200 OK\nShall be returned when the list of subscriptions was queried successfully.\nThe response body shall contain in an array the representations of all active subscriptions of the functional\nblock that invokes the method which match the attribute filter, i.e. zero or more representations of VNF\nindicators subscriptions as defined in clause 8.5.2.4. If the \"filter\" URI parameter was supplied in the request,\nthe data in the response body shall have been transformed according to the rules specified in clause 5.2.2 of\nETSI GS NFV SOL 013. If the EM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013\nfor this resource, inclusion of the Link HTTP header in this response shall follow the provisions in clause 5.4.2.3\nof ETSI GS NFV-SOL 013.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a subscription related to notifications about VNF indicator value changes.\n","type":"object","required":["id","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter for notifications related to VNF indicators.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdIds"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tVnfIndicatorValueChangeNotification -\tSupportedIndicatorsChangeNotification See note.\n","type":"string","enum":["VnfIndicatorValueChangeNotification","SupportedIndicatorsChangeNotification"]},"indicatorIds":{"description":"Match particular VNF indicator identifiers.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}}}},"callbackUri":{"description":"The URI of the endpoint to send the notification to.\n","type":"string","format":"url"},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"VnfIndicatorSubscription.Post.201":{"description":"201 CREATED\nShall be returned when the subscription has been created successfully. The response body shall contain a\nrepresentation of the created \"Individual subscription\" resource.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"Pointer to the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"URI"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a subscription related to notifications about VNF indicator value changes.\n","type":"object","required":["id","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter for notifications related to VNF indicators.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdIds"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tVnfIndicatorValueChangeNotification -\tSupportedIndicatorsChangeNotification See note.\n","type":"string","enum":["VnfIndicatorValueChangeNotification","SupportedIndicatorsChangeNotification"]},"indicatorIds":{"description":"Match particular VNF indicator identifiers.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}}}},"callbackUri":{"description":"The URI of the endpoint to send the notification to.\n","type":"string","format":"url"},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"VnfIndicatorSubscription.Post.422":{"description":"422 Unprocessable Content\n\nShall be returned upon the following error: The content type of the message content is supported\nand the message content of a request contains syntactically correct data but the data cannot be processed.\nThe general cause for this error and its handling is specified in clause 6.4 of ETSI GS NFV-SOL 013,\nincluding rules for the presence of the response body.\nSpecifically in case of this resource, the response code 422 shall also be returned if the VNFM has tested\nthe Notification endpoint as described in clause 8.4.7.3.2 and the test has failed.\nIn this case, the \"detail\" attribute in the \"ProblemDetails\" structure shall convey more information\nabout the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"VnfIndicatorSubscription.Get.200":{"description":"200 OK\nShall be returned when information about an individual subscription has been read successfully.\nThe response body shall contain the representation of the \"Individual subscription\" resource.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a subscription related to notifications about VNF indicator value changes.\n","type":"object","required":["id","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter for notifications related to VNF indicators.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdIds"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tVnfIndicatorValueChangeNotification -\tSupportedIndicatorsChangeNotification See note.\n","type":"string","enum":["VnfIndicatorValueChangeNotification","SupportedIndicatorsChangeNotification"]},"indicatorIds":{"description":"Match particular VNF indicator identifiers.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}}}},"callbackUri":{"description":"The URI of the endpoint to send the notification to.\n","type":"string","format":"url"},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"VnfIndicatorSubscription.Delete.204":{"description":"204 NO CONTENT\nShall be returned when the subscription has been deleted successfully. The response body shall be empty.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{}}}}} diff --git a/v5.3.1/SOL002-VNFIndicator-API.yaml b/v5.3.1/SOL002-VNFIndicator-API.yaml new file mode 100644 index 00000000..8a58e8a5 --- /dev/null +++ b/v5.3.1/SOL002-VNFIndicator-API.yaml @@ -0,0 +1,10747 @@ +openapi: 3.0.2 +info: + title: SOL002 - VNF Indicator interface + description: | + SOL002 - VNF Indicator interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '1.13.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 002 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/05.03.01_60/gs_NFV-SOL002v050301p.pdf +servers: + - url: 'http://127.0.0.1/vnfind/v1' + - url: 'https://127.0.0.1/vnfind/v1' +paths: + /api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /indicators: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: | + The GET method queries multiple VNF indicators. See clause 8.4.2.3.2. + parameters: + - $ref: '#/components/parameters/filter_indicators' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [6] for this + resource. + in: query + required: false + schema: + type: string + responses: + '200': + $ref: '#/components/responses/Indicators.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/indicators/{vnfInstanceId}': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The GET method queries multiple VNF indicators related to a VNF + instance. See clause 8.4.3.3.2. + parameters: + - $ref: >- + #/components/parameters/filter_vnf_indicators_related_to_vnf_instance + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [6] for this + resource. + in: query + required: false + schema: + type: string + responses: + '200': + $ref: '#/components/responses/VnfIndicators.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/indicators/{vnfInstanceId}/{indicatorId}': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + - $ref: '#/components/parameters/IndicatorId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: | + The GET method reads a VNF indicator. See clause 8.4.4.3.2. + responses: + '200': + $ref: '#/components/responses/VnfIndividualIndicator.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /subscriptions: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The GET method queries the list of active subscriptions of the + functional block that invokes the method. + + It can be used e.g. for resynchronization after error situations. See + clause 8.4.5.3.2. + parameters: + - $ref: '#/components/parameters/filter_subscriptions' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [6] for this + resource. + in: query + required: false + schema: + type: string + responses: + '200': + $ref: '#/components/responses/VnfIndicatorSubscriptions.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: | + The POST method creates a new subscription. See clause 8.4.5.3.1. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/VnfIndicatorSubscriptionRequest' + responses: + '201': + $ref: '#/components/responses/VnfIndicatorSubscription.Post.201' + '303': + description: | + 303 See Other + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/VnfIndicatorSubscription.Post.422' + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/subscriptions/{subscriptionId}': + parameters: + - $ref: '#/components/parameters/SubscriptionId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: | + The GET method reads an individual subscription. See clause 8.4.6.3.2. + responses: + '200': + $ref: '#/components/responses/VnfIndicatorSubscription.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + The DELETE method terminates an individual subscription. See clause + 8.4.6.3.5. + responses: + '204': + $ref: '#/components/responses/VnfIndicatorSubscription.Delete.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + parameters: + filter_subscriptions: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013. The EM shall and the VNF may support receiving this + parameter as part of the URI query string. The VNFM may supply this + parameter. All attribute names that appear in the + VnfIndicatorSubscription data type and in data types referenced from it + shall be supported in the filter expression. If receiving, this + parameter is not supported, a 400 Bad Request response shall be returned + (see table 8.4.5.3.2-2). + in: query + required: false + schema: + type: string + filter_vnf_indicators_related_to_vnf_instance: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013. The API producer shall support receiving this parameter as + part of the URI query string. The VNFM may supply this parameter. All + attribute names that appear in the VnfIndicator data type and in data + types referenced from it shall be supported by the API producer in the + filter expression. + in: query + required: false + schema: + type: string + filter_indicators: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013. The API producer shall support receiving this parameter as + part of the URI query string. The VNFM may supply this parameter. All + attribute names that appear in the VnfIndicator data type and in data + types referenced from it shall be supported by the API producer in the + filter expression. + in: query + required: false + schema: + type: string + VnfInstanceId: + name: vnfInstanceId + in: path + description: > + Service Unavailable. + + Identifier of the VNF instance to which the VNF indicators applies. + + NOTE: This identifier can be retrieved from the resource referenced by + the "Location" HTTP header in the + + response to a POST request creating a new VNF instance resource. It can + also be retrieved from the "id" + + attribute in the message content of that response. + required: true + style: simple + explode: false + schema: + type: string + IndicatorId: + name: indicatorId + in: path + description: > + Identifier of the VNF indicator. + + NOTE: This identifier can be retrieved from the resource referenced by + the message content in the + + response to a POST request creating a new "Individual VNF instance" + resource. + required: true + style: simple + explode: false + schema: + type: string + SubscriptionId: + name: subscriptionId + in: path + description: > + Identifier of this subscription. NOTE: + + This identifier can be retrieved from the resource referenced by the + "Location" HTTP header + + in the response to a POST request creating a new subscription resource. + It can also be retrieved + + from the "id" attribute in the message content of that response. + required: true + style: simple + explode: false + schema: + type: string + requestBodies: + VnfIndicatorSubscriptionRequest: + description: Details of the subscription to be created. + content: + application/json: + schema: + description: > + This type represents a subscription request related to VNF + indicator value change notifications. + type: object + required: + - callbackUri + properties: + filter: + description: "This type represents a subscription filter for notifications related to VNF indicators.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdIds + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId values + listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, from + one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tVnfIndicatorValueChangeNotification -\tSupportedIndicatorsChangeNotification See note.\n" + type: string + enum: + - VnfIndicatorValueChangeNotification + - SupportedIndicatorsChangeNotification + indicatorIds: + description: | + Match particular VNF indicator identifiers. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + authentication: + description: > + * NOTE 1 : The clientId and clientPassword passed in a + subscription shall not be the same as the clientId and + clientPassword that are used to obtain authorization for API requests. Client credentials may differ between + subscriptions. The value of clientPassword should be generated by a random process. + * NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT + which uses mutual authentication based on X.509 + certificates, this mode which uses client password to authenticate may be used in the access token request + toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations + (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details. + * NOTE 3: The following values that were included up to + version 3.4.1 of the present document have been removed: + "BASIC" (to signal the use of the basic HTTP authentication) has been removed because it is insecure. + "TLS_CERT" to signal an alternative non-token based authorization method using TLS certificates has been + removed because the method is no longer supported. + * NOTE 4: The client certificate is established by means + outside the scope of the present document. + type: object + required: + - authType + properties: + authType: + description: > + Defines the types of Authentication / Authorization which + the API consumer is willing to accept when receiving a + notification. Permitted values (see note 3): * + OAUTH2_CLIENT_CREDENTIALS: In every + HTTP request to the notification endpoint, use + an OAuth 2.0 token, obtained using the client + credentials grant type after authenticating + using client identifier and client password + towards the token endpoint. + * OAUTH2_CLIENT_CERT: In every HTTP + request to the notification endpoint, use an + OAuth 2.0 token, obtained using the client + credentials grant type after mutually + authenticating using client identifier and X.509 + certificates towards the token endpoint. + type: array + items: + type: string + enum: + - OAUTH2_CLIENT_CREDENTIALS + - OAUTH2_CLIENT_CERT + paramsOauth2ClientCert: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CERT. + + Shall be present if authType is "OAUTH2_CLIENT_CERT" and + the contained information has not been provisioned out of + band. + + Shall be absent otherwise. + type: object + required: + - clientId + - certificateRef + - tokenEndpoint + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. + type: string + certificateRef: + description: > + Fingerprint of the client certificate. The hash + function shall use SHA256 or higher. See note 4. + type: string + required: + - type + - value + properties: + type: + description: | + A string defined in IETF RFC 8259. + type: string + value: + description: | + A string defined in IETF RFC 8259. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + paramsOauth2ClientCredentials: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CREDENTIALS. + + Shall be present if authType is + "OAUTH2_CLIENT_CREDENTIALS" and the contained information + has not been provisioned out of band. + + Shall be absent otherwise. + + See note 2. + type: object + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. Shall be present if it has not been + provisioned out of band. See note 1. + type: string + clientPassword: + description: > + Client password to be used in the access token request + of the OAuth 2.0 client credentials grant type. Shall + be present if it has not been provisioned out of band. + See note 1. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + responses: + Indicators.Get.200: + description: > + 200 OK + + Shall be returned when information about zero or more VNF indicators + was queried successfully. + + The response body shall contain in an array the representations of all + VNF indicators that match the + + attribute-based filtering parameters, i.e. zero or more representations + of VNF indicators as defined + + in clause 8.5.2.2. If the "filter" URI parameter was supplied in the + request, the data in the response + + body shall have been transformed according to the rules specified in + clause 5.2.2 of ETSI GS NFV-SOL 013. + + If the EM/VNF supports alternative 2 (paging) according to clause + 5.4.2.1 of ETSI GS NFV-SOL 013for this + + resource, inclusion of the Link HTTP header in this response shall + follow the provisions in clause 5.4.2.3 + + of ETSI GS NFV-SOL 013. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: "This type represents a VNF indicator value.\nNOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n" + type: object + required: + - id + - value + - vnfInstanceId + - _links + properties: + id: + description: | + An identifier that is unique within a VNF descriptor. + type: string + name: + description: > + Human readable name of the indicator. Shall be present if + defined in the VNFD. + type: string + value: + description: > + Provides the value of the indicator. The value format is + defined in the VNFD. See note. + type: object + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfcInstanceIds: + description: > + The vnfcInstanceIds attribute is optionally present. If + present, it contains the list of identifiers of VNFC + instances which provide the indicator value(s). + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + - vnfInstance + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + VnfIndicators.Get.200: + description: > + 200 OK + + Shall be returned when information about zero or more VNF indicators + was queried successfully. + + The response body shall contain in an array the representations of all + VNF indicators that are related + + to the particular VNF instance and that match the attribute filter., + i.e. zero or more representations + + of VNF indicators as defined in clause 8.5.2.2. If the "filter" URI + parameter was supplied in the request, + + the data in the response body shall have been transformed according to + the rules specified in clause + + 5.2.2 of ETSI GS NFV-SOL 013. If the EM/VMF supports alternative 2 + (paging) according to clause 5.4.2.1 of + + ETSI GS NFV-SOL 013 for this resource, inclusion of the Link HTTP + header in this response shall follow the + + provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: "This type represents a VNF indicator value.\nNOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n" + type: object + required: + - id + - value + - vnfInstanceId + - _links + properties: + id: + description: | + An identifier that is unique within a VNF descriptor. + type: string + name: + description: > + Human readable name of the indicator. Shall be present if + defined in the VNFD. + type: string + value: + description: > + Provides the value of the indicator. The value format is + defined in the VNFD. See note. + type: object + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfcInstanceIds: + description: > + The vnfcInstanceIds attribute is optionally present. If + present, it contains the list of identifiers of VNFC + instances which provide the indicator value(s). + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + - vnfInstance + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + VnfIndividualIndicator.Get.200: + description: > + 200 OK + + Shall be returned when the VNF indicator has been read successfully. The + response body shall contain the + + representation of the VNF indicator. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: "This type represents a VNF indicator value.\nNOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n" + type: object + required: + - id + - value + - vnfInstanceId + - _links + properties: + id: + description: | + An identifier that is unique within a VNF descriptor. + type: string + name: + description: > + Human readable name of the indicator. Shall be present if + defined in the VNFD. + type: string + value: + description: > + Provides the value of the indicator. The value format is + defined in the VNFD. See note. + type: object + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfcInstanceIds: + description: > + The vnfcInstanceIds attribute is optionally present. If + present, it contains the list of identifiers of VNFC + instances which provide the indicator value(s). + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + - vnfInstance + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + VnfIndicatorSubscriptions.Get.200: + description: > + 200 OK + + Shall be returned when the list of subscriptions was queried + successfully. + + The response body shall contain in an array the representations of all + active subscriptions of the functional + + block that invokes the method which match the attribute filter, i.e. + zero or more representations of VNF + + indicators subscriptions as defined in clause 8.5.2.4. If the "filter" + URI parameter was supplied in the request, + + the data in the response body shall have been transformed according to + the rules specified in clause 5.2.2 of + + ETSI GS NFV SOL 013. If the EM supports alternative 2 (paging) according + to clause 5.4.2.1 of ETSI GS NFV-SOL 013 + + for this resource, inclusion of the Link HTTP header in this response + shall follow the provisions in clause 5.4.2.3 + + of ETSI GS NFV-SOL 013. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: > + This type represents a subscription related to notifications + about VNF indicator value changes. + type: object + required: + - id + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: "This type represents a subscription filter for notifications related to VNF indicators.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdIds + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId + values listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, + from one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tVnfIndicatorValueChangeNotification -\tSupportedIndicatorsChangeNotification See note.\n" + type: string + enum: + - VnfIndicatorValueChangeNotification + - SupportedIndicatorsChangeNotification + indicatorIds: + description: | + Match particular VNF indicator identifiers. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + callbackUri: + description: | + The URI of the endpoint to send the notification to. + type: string + format: url + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + VnfIndicatorSubscription.Post.201: + description: > + 201 CREATED + + Shall be returned when the subscription has been created successfully. + The response body shall contain a + + representation of the created "Individual subscription" resource. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Location: + description: | + Pointer to the created subscription resource. + style: simple + explode: false + schema: + type: string + format: URI + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: > + This type represents a subscription related to notifications + about VNF indicator value changes. + type: object + required: + - id + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: "This type represents a subscription filter for notifications related to VNF indicators.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdIds + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId + values listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, + from one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tVnfIndicatorValueChangeNotification -\tSupportedIndicatorsChangeNotification See note.\n" + type: string + enum: + - VnfIndicatorValueChangeNotification + - SupportedIndicatorsChangeNotification + indicatorIds: + description: | + Match particular VNF indicator identifiers. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + callbackUri: + description: | + The URI of the endpoint to send the notification to. + type: string + format: url + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + VnfIndicatorSubscription.Post.422: + description: > + 422 Unprocessable Content + + + Shall be returned upon the following error: The content type of the + message content is supported + + and the message content of a request contains syntactically correct data + but the data cannot be processed. + + The general cause for this error and its handling is specified in clause + 6.4 of ETSI GS NFV-SOL 013, + + including rules for the presence of the response body. + + Specifically in case of this resource, the response code 422 shall also + be returned if the VNFM has tested + + the Notification endpoint as described in clause 8.4.7.3.2 and the test + has failed. + + In this case, the "detail" attribute in the "ProblemDetails" structure + shall convey more information + + about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: Version of the API used in the response. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + VnfIndicatorSubscription.Get.200: + description: > + 200 OK + + Shall be returned when information about an individual subscription has + been read successfully. + + The response body shall contain the representation of the "Individual + subscription" resource. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + This type represents a subscription related to notifications about + VNF indicator value changes. + type: object + required: + - id + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: "This type represents a subscription filter for notifications related to VNF indicators.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdIds + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId values + listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, from + one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tVnfIndicatorValueChangeNotification -\tSupportedIndicatorsChangeNotification See note.\n" + type: string + enum: + - VnfIndicatorValueChangeNotification + - SupportedIndicatorsChangeNotification + indicatorIds: + description: | + Match particular VNF indicator identifiers. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + callbackUri: + description: | + The URI of the endpoint to send the notification to. + type: string + format: url + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + VnfIndicatorSubscription.Delete.204: + description: > + 204 NO CONTENT + + Shall be returned when the subscription has been deleted successfully. + The response body shall be empty. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + content: {} + diff --git a/v5.3.1/SOL002-VNFIndicatorNotification-API.json b/v5.3.1/SOL002-VNFIndicatorNotification-API.json new file mode 100644 index 00000000..de73cae8 --- /dev/null +++ b/v5.3.1/SOL002-VNFIndicatorNotification-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL002 - VNF Indicator Notification interface","description":"SOL002 - VNF Indicator Notification interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"1.13.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 002 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/05.03.01_60/gs_NFV-SOL002v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/callback/v1"},{"url":"https://127.0.0.1/callback/v1"}],"paths":{"/URI_is_provided_by_the_client_when_creating_the_subscription-VnfIndicatorValueChangeNotification":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method allows the API producer to test the notification endpoint that is provided by the\nAPI consumer, e.g. during subscription. See clause 8.4.7.3.2.\n","responses":{"204":{"$ref":"#/components/responses/VNFInNotification.Get.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"The POST method delivers a notification from the API producer to an API consumer. The API consumer shall have\npreviously created an \"Individual subscription\" resource with a matching filter. See clause 8.4.7.3.1.\n","parameters":[{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/VnfIndicatorValueChangeNotification"},"responses":{"204":{"$ref":"#/components/responses/VNFInNotification.Post.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/URI_is_provided_by_the_client_when_creating_the_subscription-SupportedIndicatorsChangeNotification":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method allows the API producer to test the notification endpoint that is provided by the\nAPI consumer, e.g. during subscription. See clause 8.4.7.3.2.\n","responses":{"204":{"$ref":"#/components/responses/VNFInNotification.Get.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"The POST method delivers a notification from the API producer to an API consumer. The API consumer shall have\npreviously created an \"Individual subscription\" resource with a matching filter. See clause 8.4.7.3.1.\n","parameters":[{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/SupportedIndicatorsChangeNotification"},"responses":{"204":{"$ref":"#/components/responses/VNFInNotification.Post.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"requestBodies":{"VnfIndicatorValueChangeNotification":{"description":"A notification about VNF indicator value changes.\n","content":{"application/json":{"schema":{"description":"This type represents a VNF indicator value change notification. * NOTE:\tETSI GS NFV-SOL 001 specifies the structure and\n format of the VNFD based on TOSCA specifications.\n","type":"object","required":["id","notificationType","subscriptionId","timeStamp","vnfIndicatorId","value","vnfInstanceId","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"VnfIndicatorValueChangeNotification\" for this notification type.\n","type":"string"},"subscriptionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfIndicatorId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Human readable name of the VNF indicator. Shall be present if defined in the VNFD.\n","type":"string"},"value":{"description":"Provides the value of the VNF indicator. The value format is defined in the VNFD. See note.\n","type":"object"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["vnfInstance","subscription"],"properties":{"vnfInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"subscription":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true},"SupportedIndicatorsChangeNotification":{"description":"A notification about changes of the set of supported indicators.\n","content":{"application/json":{"schema":{"description":"This type represents a notification to inform the receiver that the set of indicators\nsupported by a VNF instance has changed.\n* NOTE:\tETSI GS NFV-SOL 001 specifies the structure and\n format of the VNFD based on TOSCA specifications.\n","type":"object","required":["id","notificationType","subscriptionId","timeStamp","vnfInstanceId"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"SupportedIndicatorsChangeNotification\"\nfor this notification type.\n","type":"string"},"subscriptionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"supportedIndicators":{"description":"Set of VNF indicators supported by the VNF instance.\n","type":"array","items":{"type":"object","required":["vnfIndicatorId"],"properties":{"vnfIndicatorId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"name":{"description":"Human readable name of the VNF indicator. Shall be present if defined in the VNFD.\nSee note.\n","type":"string"}}}},"_links":{"description":"Links for this resource.\n","type":"object","required":["subscription"],"properties":{"vnfInstance":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"subscription":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true}},"responses":{"VNFInNotification.Get.204":{"description":"204 NO CONTENT\nShall be returned to indicate the notification endpoint has been tested successfully. The response body\nshall be empty.\n","headers":{"Version":{"description":"Version of the API used in the response.\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{}},"VNFInNotification.Post.204":{"description":"204 NO CONTENT\nShall be returned when the notification has been delivered successfully. The response body shall be empty.\n","headers":{"Version":{"description":"Version of the API used in the response.\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{}}}}} diff --git a/v5.3.1/SOL002-VNFIndicatorNotification-API.yaml b/v5.3.1/SOL002-VNFIndicatorNotification-API.yaml new file mode 100644 index 00000000..d80a780b --- /dev/null +++ b/v5.3.1/SOL002-VNFIndicatorNotification-API.yaml @@ -0,0 +1,3079 @@ +openapi: 3.0.2 +info: + title: SOL002 - VNF Indicator Notification interface + description: | + SOL002 - VNF Indicator Notification interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '1.13.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 002 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/05.03.01_60/gs_NFV-SOL002v050301p.pdf +servers: + - url: 'http://127.0.0.1/callback/v1' + - url: 'https://127.0.0.1/callback/v1' +paths: + /URI_is_provided_by_the_client_when_creating_the_subscription-VnfIndicatorValueChangeNotification: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The GET method allows the API producer to test the notification endpoint + that is provided by the + + API consumer, e.g. during subscription. See clause 8.4.7.3.2. + responses: + '204': + $ref: '#/components/responses/VNFInNotification.Get.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + The POST method delivers a notification from the API producer to an API + consumer. The API consumer shall have + + previously created an "Individual subscription" resource with a matching + filter. See clause 8.4.7.3.1. + parameters: + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/VnfIndicatorValueChangeNotification' + responses: + '204': + $ref: '#/components/responses/VNFInNotification.Post.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /URI_is_provided_by_the_client_when_creating_the_subscription-SupportedIndicatorsChangeNotification: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The GET method allows the API producer to test the notification endpoint + that is provided by the + + API consumer, e.g. during subscription. See clause 8.4.7.3.2. + responses: + '204': + $ref: '#/components/responses/VNFInNotification.Get.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + The POST method delivers a notification from the API producer to an API + consumer. The API consumer shall have + + previously created an "Individual subscription" resource with a matching + filter. See clause 8.4.7.3.1. + parameters: + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/SupportedIndicatorsChangeNotification' + responses: + '204': + $ref: '#/components/responses/VNFInNotification.Post.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + requestBodies: + VnfIndicatorValueChangeNotification: + description: | + A notification about VNF indicator value changes. + content: + application/json: + schema: + description: "This type represents a VNF indicator value change notification. * NOTE:\tETSI GS NFV-SOL 001 specifies the structure and\n format of the VNFD based on TOSCA specifications.\n" + type: object + required: + - id + - notificationType + - subscriptionId + - timeStamp + - vnfIndicatorId + - value + - vnfInstanceId + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall be + set to "VnfIndicatorValueChangeNotification" for this + notification type. + type: string + subscriptionId: + description: | + An identifier with the intention of being globally unique. + type: string + timeStamp: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + vnfIndicatorId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + name: + description: > + Human readable name of the VNF indicator. Shall be present if + defined in the VNFD. + type: string + value: + description: > + Provides the value of the VNF indicator. The value format is + defined in the VNFD. See note. + type: object + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + _links: + description: | + Links to resources related to this resource. + type: object + required: + - vnfInstance + - subscription + properties: + vnfInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + subscription: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + SupportedIndicatorsChangeNotification: + description: | + A notification about changes of the set of supported indicators. + content: + application/json: + schema: + description: "This type represents a notification to inform the receiver that the set of indicators\nsupported by a VNF instance has changed.\n* NOTE:\tETSI GS NFV-SOL 001 specifies the structure and\n format of the VNFD based on TOSCA specifications.\n" + type: object + required: + - id + - notificationType + - subscriptionId + - timeStamp + - vnfInstanceId + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall be + set to "SupportedIndicatorsChangeNotification" + + for this notification type. + type: string + subscriptionId: + description: | + An identifier with the intention of being globally unique. + type: string + timeStamp: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + supportedIndicators: + description: | + Set of VNF indicators supported by the VNF instance. + type: array + items: + type: object + required: + - vnfIndicatorId + properties: + vnfIndicatorId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + name: + description: > + Human readable name of the VNF indicator. Shall be + present if defined in the VNFD. + + See note. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - subscription + properties: + vnfInstance: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + subscription: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + responses: + VNFInNotification.Get.204: + description: > + 204 NO CONTENT + + Shall be returned to indicate the notification endpoint has been tested + successfully. The response body + + shall be empty. + headers: + Version: + description: | + Version of the API used in the response. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + content: {} + VNFInNotification.Post.204: + description: > + 204 NO CONTENT + + Shall be returned when the notification has been delivered successfully. + The response body shall be empty. + headers: + Version: + description: | + Version of the API used in the response. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + content: {} + diff --git a/v5.3.1/SOL002-VNFLifecycleCoordination-API.json b/v5.3.1/SOL002-VNFLifecycleCoordination-API.json new file mode 100644 index 00000000..1a224d76 --- /dev/null +++ b/v5.3.1/SOL002-VNFLifecycleCoordination-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL002 - VNF LCM Coordination interface","description":"SOL002 - VNF Lifecycle Coordination Interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"1.12.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 002 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/05.03.01_60/gs_NFV-SOL002v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/lcmcoord/v1"},{"url":"https://127.0.0.1/lcmcoord/v1"}],"paths":{"/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/coordinations":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"This POST method requests the coordination of an LCM operation occurrence with\na management operation executed in the API producer. See clause 10.4.2.3.1.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/LcmCoordRequest"},"responses":{"201":{"$ref":"#/components/responses/Coordination.Post.201"},"202":{"$ref":"#/components/responses/Coordination_async.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/Coordination.Post.403"},"404":{"description":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/Coordination.Post.409"},"422":{"description":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/Coordination.Post.503"},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/coordinations/{coordinationId}":{"parameters":[{"$ref":"#/components/parameters/coordinationId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method reads a coordination result. See clause 10.4.3.3.2.\n","responses":{"200":{"$ref":"#/components/responses/LcmCoord.Get.200"},"202":{"$ref":"#/components/responses/LcmCoord.Get.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/coordinations/{coordinationId}/cancel":{"parameters":[{"$ref":"#/components/parameters/coordinationId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"The POST method initiates the cancellation of an ongoing coordination action.\nSee clause 10.4.4.3.1.\n","responses":{"202":{"$ref":"#/components/responses/CoordinationCancel.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/CoordinationCancel.Post.409"},"422":{"description":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"parameters":{"coordinationId":{"name":"coordinationId","in":"path","description":"Identifier of the LCM coordination. This identifier can be retrieved from the\nresource referenced by the \"Location\" HTTP header in the response to a\nPOST request to the \"Coordinations\" resource\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}}},"requestBodies":{"LcmCoordRequest":{"description":"Parameters for the coordination action as defined in clause 10.5.2.2.\n","content":{"application/json":{"schema":{"type":"object","required":["vnfInstanceId","vnfLcmOpOccId","lcmOperationType","coordinationActionName","_links"],"properties":{"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLcmOpOccId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"lcmOperationType":{"description":"The enumeration LcmOperationForCoordType defines the permitted values to represent VNF lifecycle operation types in VNF LCM operation coordination actions. * INSTANTIATE: Represents the \"Instantiate VNF\" LCM operation. * SCALE: Represents the \"Scale VNF\" LCM operation. * SCALE_TO_LEVEL: Represents the \"Scale VNF to Level\" LCM operation. * CHANGE_FLAVOUR: Represents the \"Change VNF Flavour\" LCM operation. * TERMINATE: Represents the \"Terminate VNF\" LCM operation. * HEAL: Represents the \"Heal VNF\" LCM operation. * OPERATE: Represents the \"Operate VNF\" LCM operation. * CHANGE_EXT_CONN: Represents the \"Change external VNF connectivity\" LCM operation. * MODIFY_INFO: Represents the \"Modify VNF Information\" LCM operation. * CREATE_SNAPSHOT: Represents the \"Create VNF Snapshot\" LCM operation. * REVERT_TO_SNAPSHOT: Represents the \"Revert To VNF Snapshot\" LCM operation. * CHANGE_VNFPKG: Represents the \"Change current VNF package\" LCM operation.\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","MODIFY_INFO","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","CHANGE_VNFPKG"]},"coordinationActionName":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"inputParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this request.\n","type":"object","required":["vnfLcmOpOcc","vnfInstance"],"properties":{"vnfLcmOpOcc":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true}},"responses":{"Coordination.Post.201":{"description":"201 CREATED\nShall be returned returned to indicate a finished coordination action when the API producer has\nchosen the synchronous mode, which may be selected for coordination actions that finish within the time\nframe in which an HTTP response is expected.\nThe response body shall contain an LcmCoord data structure that represents\nthe result of the coordination action.\nThe HTTP response shall include a \"Location\" HTTP header that indicates the URI\nof the \"Individual coordination action\" resource that has been created as the\nresult of the finished coordination procedure.\n","headers":{"Version":{"description":"The used API version.\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"URI of the \"Individual coordination action\" resource\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{"application/json":{"schema":{"description":"This type represents an LCM coordination result.\n","type":"object","required":["id","coordinationResult","vnfInstanceId","vnfLcmOpOccId","lcmOperationType","coordinationActionName","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"coordinationResult":{"description":"The enumeration LcmCoordResultType defines the permitted values to represent the result of executing an LCM coordination action. The coordination result also implies the action to be performed by the VNFM as the follow-up to this coordination. Value | Description ------|------------ CONTINUE | The related LCM operation shall be continued, staying in the state \"PROCESSING\". ABORT | The related LCM operation shall be aborted by transitioning into the state \"FAILED_TEMP\". CANCELLED | The coordination action has been cancelled upon request of the API consumer, i.e. the VNFM. The related LCM operation shall be aborted by transitioning into the state \"FAILED_TEMP\".\n","type":"string","enum":["CONTINUE","ABORT","CANCELLED"]},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLcmOpOccId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"lcmOperationType":{"description":"The enumeration LcmOperationForCoordType defines the permitted values to represent VNF lifecycle operation types in VNF LCM operation coordination actions. * INSTANTIATE: Represents the \"Instantiate VNF\" LCM operation. * SCALE: Represents the \"Scale VNF\" LCM operation. * SCALE_TO_LEVEL: Represents the \"Scale VNF to Level\" LCM operation. * CHANGE_FLAVOUR: Represents the \"Change VNF Flavour\" LCM operation. * TERMINATE: Represents the \"Terminate VNF\" LCM operation. * HEAL: Represents the \"Heal VNF\" LCM operation. * OPERATE: Represents the \"Operate VNF\" LCM operation. * CHANGE_EXT_CONN: Represents the \"Change external VNF connectivity\" LCM operation. * MODIFY_INFO: Represents the \"Modify VNF Information\" LCM operation. * CREATE_SNAPSHOT: Represents the \"Create VNF Snapshot\" LCM operation. * REVERT_TO_SNAPSHOT: Represents the \"Revert To VNF Snapshot\" LCM operation. * CHANGE_VNFPKG: Represents the \"Change current VNF package\" LCM operation.\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","MODIFY_INFO","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","CHANGE_VNFPKG"]},"coordinationActionName":{"description":"Indicates the actual LCM coordination action. The coordination actions that a VNF supports are declared in the VNFD.\n","type":"string"},"outputParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"warnings":{"description":"Warning messages that were generated while the operation was executing.\n","type":"string"},"error":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self","vnfLcmOpOcc","vnfInstance"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfLcmOpOcc":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"Coordination_async.Post.202":{"description":"202 ACCEPTED\nShall be returned when the API producer has chosen the asynchronous mode and the\nrequest has been accepted for processing.\nThe response body shall be empty.\nThe HTTP response shall include a \"Location\" HTTP header that indicates the URI of\nthe \"Individual coordination action\" resource that will be created once the\ncoordination operation has finished successfully.\nFurther, the HTTP response may include a \"Retry-After\" HTTP header that indicates the\ntime to wait before sending the next GET request to the \"individual coordination\" resource\nindicated in the \"Location\" header. If the header is provided, the VNFM shall record the signalled\ndelay value in the \"delay\" attribute of the applicable entry in the \"lcmCoordinations\" array in the\n\"VnfLcmOpOcc\" structure.\n","headers":{"Version":{"description":"The used API version.\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"Used in redirection, or when a new resource has been created. This header field shall be present if the\nresponse status code is 201 or 3xx. In the present document this header field is also used if the response\nstatus code is 202 and a new resource was created.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{}},"Coordination.Post.403":{"description":"403 FORBIDDEN\nShall be returned upon the following error: The starting of the coordination operation has been rejected. No \"individual coordination action\" resource shall be created. A ProblemDetails structure shall be included in the response to provide more details about the rejection in the \"details\" attribute.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"Coordination.Post.409":{"description":"409 CONFLICT\nShall be returned upon the following error: The operation cannot be executed currently, due to a conflict with the state of the \"Coordinations\" resource. Typically, this is due to the fact that no more coordination actions can be executed currently e.g. because too many of them, or conflicting ones, are in progress. The response body shall 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"Coordination.Post.503":{"description":"503 SERVICE UNAVAILABLE\nShall be returned upon the following error: The API producer has chosen the synchronous mode and cannot perform the requested coordination currently, but expects to be able to perform it sometime in the future. No \"individual coordination action\" resource shall be created. A ProblemDetails structure shall be included in the response to provide more details about the rejection in the \"details\" attribute. The HTTP response shall include a \"Retry-After\" HTTP header that indicates the delay after which it is suggested to repeat the coordination request with the same set of parameters. The VNFM shall record the signalled delay value in the \"delay\" attribute of the applicable entry in the \"rejectedLcmCoordinations\" array in the \"VnfLcmOpOcc\" structure.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"LcmCoord.Get.200":{"description":"200 OK\nShall be returned when the coordination is finished and the coordination result has been read successfully.\nA representation of the \"Individual coordination action\" resource shall be returned in the response body.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents an LCM coordination result.\n","type":"object","required":["id","coordinationResult","vnfInstanceId","vnfLcmOpOccId","lcmOperationType","coordinationActionName","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"coordinationResult":{"description":"The enumeration LcmCoordResultType defines the permitted values to represent the result of executing an LCM coordination action. The coordination result also implies the action to be performed by the VNFM as the follow-up to this coordination. Value | Description ------|------------ CONTINUE | The related LCM operation shall be continued, staying in the state \"PROCESSING\". ABORT | The related LCM operation shall be aborted by transitioning into the state \"FAILED_TEMP\". CANCELLED | The coordination action has been cancelled upon request of the API consumer, i.e. the VNFM. The related LCM operation shall be aborted by transitioning into the state \"FAILED_TEMP\".\n","type":"string","enum":["CONTINUE","ABORT","CANCELLED"]},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLcmOpOccId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"lcmOperationType":{"description":"The enumeration LcmOperationForCoordType defines the permitted values to represent VNF lifecycle operation types in VNF LCM operation coordination actions. * INSTANTIATE: Represents the \"Instantiate VNF\" LCM operation. * SCALE: Represents the \"Scale VNF\" LCM operation. * SCALE_TO_LEVEL: Represents the \"Scale VNF to Level\" LCM operation. * CHANGE_FLAVOUR: Represents the \"Change VNF Flavour\" LCM operation. * TERMINATE: Represents the \"Terminate VNF\" LCM operation. * HEAL: Represents the \"Heal VNF\" LCM operation. * OPERATE: Represents the \"Operate VNF\" LCM operation. * CHANGE_EXT_CONN: Represents the \"Change external VNF connectivity\" LCM operation. * MODIFY_INFO: Represents the \"Modify VNF Information\" LCM operation. * CREATE_SNAPSHOT: Represents the \"Create VNF Snapshot\" LCM operation. * REVERT_TO_SNAPSHOT: Represents the \"Revert To VNF Snapshot\" LCM operation. * CHANGE_VNFPKG: Represents the \"Change current VNF package\" LCM operation.\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","MODIFY_INFO","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","CHANGE_VNFPKG"]},"coordinationActionName":{"description":"Indicates the actual LCM coordination action. The coordination actions that a VNF supports are declared in the VNFD.\n","type":"string"},"outputParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"warnings":{"description":"Warning messages that were generated while the operation was executing.\n","type":"string"},"error":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self","vnfLcmOpOcc","vnfInstance"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfLcmOpOcc":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"LcmCoord.Get.202":{"description":"202 ACCEPTED\nShall be returned when the management operation with which coordination is requested is still ongoing or\nin the process of being cancelled, i.e. no coordination result is available yet.\nThe response shall be empty.\n","headers":{"Version":{"description":"The used API version.\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"Used in redirection, or when a new resource has been created. This header field shall be present if the\nresponse status code is 201 or 3xx. In the present document this header field is also used if the response\nstatus code is 202 and a new resource was created.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{}},"CoordinationCancel.Post.202":{"description":"202 ACCEPTED\nShall be returned when the cancellation request has been accepted for processing.\nThe response shall have an empty message content.\n","headers":{"Version":{"description":"The used API version.\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"Used in redirection, or when a new resource has been created. This header field shall be present if the\nresponse status code is 201 or 3xx. In the present document this header field is also used if the response\nstatus code is 202 and a new resource was created.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{}},"CoordinationCancel.Post.409":{"description":"409 CONFLICT\nShall be returned upon the following error: The operation cannot be executed currently, due to a conflict with the state of the \"Individual coordination action\" resource. Typically, this is due to the fact that the coordination action has finished processing. The response body shall contain a ProblemDetails structure, in which the \"detail\" attribute shall convey more information about the error.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}} diff --git a/v5.3.1/SOL002-VNFLifecycleCoordination-API.yaml b/v5.3.1/SOL002-VNFLifecycleCoordination-API.yaml new file mode 100644 index 00000000..1ae29402 --- /dev/null +++ b/v5.3.1/SOL002-VNFLifecycleCoordination-API.yaml @@ -0,0 +1,6034 @@ +openapi: 3.0.2 +info: + title: SOL002 - VNF LCM Coordination interface + description: | + SOL002 - VNF Lifecycle Coordination Interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '1.12.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 002 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/05.03.01_60/gs_NFV-SOL002v050301p.pdf +servers: + - url: 'http://127.0.0.1/lcmcoord/v1' + - url: 'https://127.0.0.1/lcmcoord/v1' +paths: + /api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /coordinations: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + post: + description: > + This POST method requests the coordination of an LCM operation + occurrence with + + a management operation executed in the API producer. See clause + 10.4.2.3.1. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/LcmCoordRequest' + responses: + '201': + $ref: '#/components/responses/Coordination.Post.201' + '202': + $ref: '#/components/responses/Coordination_async.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/Coordination.Post.403' + '404': + description: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/Coordination.Post.409' + '422': + description: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/Coordination.Post.503' + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/coordinations/{coordinationId}': + parameters: + - $ref: '#/components/parameters/coordinationId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: | + The GET method reads a coordination result. See clause 10.4.3.3.2. + responses: + '200': + $ref: '#/components/responses/LcmCoord.Get.200' + '202': + $ref: '#/components/responses/LcmCoord.Get.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/coordinations/{coordinationId}/cancel': + parameters: + - $ref: '#/components/parameters/coordinationId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + post: + description: > + The POST method initiates the cancellation of an ongoing coordination + action. + + See clause 10.4.4.3.1. + responses: + '202': + $ref: '#/components/responses/CoordinationCancel.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/CoordinationCancel.Post.409' + '422': + description: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + parameters: + coordinationId: + name: coordinationId + in: path + description: > + Identifier of the LCM coordination. This identifier can be retrieved + from the + + resource referenced by the "Location" HTTP header in the response to a + + POST request to the "Coordinations" resource + required: true + style: simple + explode: false + schema: + type: string + requestBodies: + LcmCoordRequest: + description: | + Parameters for the coordination action as defined in clause 10.5.2.2. + content: + application/json: + schema: + type: object + required: + - vnfInstanceId + - vnfLcmOpOccId + - lcmOperationType + - coordinationActionName + - _links + properties: + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfLcmOpOccId: + description: | + An identifier with the intention of being globally unique. + type: string + lcmOperationType: + description: > + The enumeration LcmOperationForCoordType defines the permitted + values to represent VNF lifecycle operation types in VNF LCM + operation coordination actions. * INSTANTIATE: Represents the + "Instantiate VNF" LCM operation. * SCALE: Represents the + "Scale VNF" LCM operation. * SCALE_TO_LEVEL: Represents the + "Scale VNF to Level" LCM operation. * CHANGE_FLAVOUR: + Represents the "Change VNF Flavour" LCM operation. * + TERMINATE: Represents the "Terminate VNF" LCM operation. * + HEAL: Represents the "Heal VNF" LCM operation. * OPERATE: + Represents the "Operate VNF" LCM operation. * CHANGE_EXT_CONN: + Represents the "Change external VNF connectivity" LCM + operation. * MODIFY_INFO: Represents the "Modify VNF + Information" LCM operation. * CREATE_SNAPSHOT: Represents the + "Create VNF Snapshot" LCM operation. * REVERT_TO_SNAPSHOT: + Represents the "Revert To VNF Snapshot" LCM operation. * + CHANGE_VNFPKG: Represents the "Change current VNF package" LCM + operation. + type: string + enum: + - INSTANTIATE + - SCALE + - SCALE_TO_LEVEL + - CHANGE_FLAVOUR + - TERMINATE + - HEAL + - OPERATE + - CHANGE_EXT_CONN + - MODIFY_INFO + - CREATE_SNAPSHOT + - REVERT_TO_SNAPSHOT + - CHANGE_VNFPKG + coordinationActionName: + description: | + An identifier that is unique within a VNF descriptor. + type: string + inputParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + _links: + description: | + Links to resources related to this request. + type: object + required: + - vnfLcmOpOcc + - vnfInstance + properties: + vnfLcmOpOcc: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + responses: + Coordination.Post.201: + description: > + 201 CREATED + + Shall be returned returned to indicate a finished coordination action + when the API producer has + + chosen the synchronous mode, which may be selected for coordination + actions that finish within the time + + frame in which an HTTP response is expected. + + The response body shall contain an LcmCoord data structure that + represents + + the result of the coordination action. + + The HTTP response shall include a "Location" HTTP header that indicates + the URI + + of the "Individual coordination action" resource that has been created + as the + + result of the finished coordination procedure. + headers: + Version: + description: | + The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: | + URI of the "Individual coordination action" resource + style: simple + explode: false + schema: + type: string + format: url + content: + application/json: + schema: + description: | + This type represents an LCM coordination result. + type: object + required: + - id + - coordinationResult + - vnfInstanceId + - vnfLcmOpOccId + - lcmOperationType + - coordinationActionName + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + coordinationResult: + description: > + The enumeration LcmCoordResultType defines the permitted + values to represent the result of executing an LCM + coordination action. The coordination result also implies the + action to be performed by the VNFM as the follow-up to this + coordination. Value | Description ------|------------ CONTINUE + | The related LCM operation shall be continued, staying in the + state "PROCESSING". ABORT | The related LCM operation shall be + aborted by transitioning into the state "FAILED_TEMP". + CANCELLED | The coordination action has been cancelled upon + request of the API consumer, i.e. the VNFM. The related LCM + operation shall be aborted by transitioning into the state + "FAILED_TEMP". + type: string + enum: + - CONTINUE + - ABORT + - CANCELLED + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfLcmOpOccId: + description: | + An identifier with the intention of being globally unique. + type: string + lcmOperationType: + description: > + The enumeration LcmOperationForCoordType defines the permitted + values to represent VNF lifecycle operation types in VNF LCM + operation coordination actions. * INSTANTIATE: Represents the + "Instantiate VNF" LCM operation. * SCALE: Represents the + "Scale VNF" LCM operation. * SCALE_TO_LEVEL: Represents the + "Scale VNF to Level" LCM operation. * CHANGE_FLAVOUR: + Represents the "Change VNF Flavour" LCM operation. * + TERMINATE: Represents the "Terminate VNF" LCM operation. * + HEAL: Represents the "Heal VNF" LCM operation. * OPERATE: + Represents the "Operate VNF" LCM operation. * CHANGE_EXT_CONN: + Represents the "Change external VNF connectivity" LCM + operation. * MODIFY_INFO: Represents the "Modify VNF + Information" LCM operation. * CREATE_SNAPSHOT: Represents the + "Create VNF Snapshot" LCM operation. * REVERT_TO_SNAPSHOT: + Represents the "Revert To VNF Snapshot" LCM operation. * + CHANGE_VNFPKG: Represents the "Change current VNF package" LCM + operation. + type: string + enum: + - INSTANTIATE + - SCALE + - SCALE_TO_LEVEL + - CHANGE_FLAVOUR + - TERMINATE + - HEAL + - OPERATE + - CHANGE_EXT_CONN + - MODIFY_INFO + - CREATE_SNAPSHOT + - REVERT_TO_SNAPSHOT + - CHANGE_VNFPKG + coordinationActionName: + description: > + Indicates the actual LCM coordination action. The coordination + actions that a VNF supports are declared in the VNFD. + type: string + outputParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + warnings: + description: > + Warning messages that were generated while the operation was + executing. + type: string + error: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + - vnfLcmOpOcc + - vnfInstance + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfLcmOpOcc: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + Coordination_async.Post.202: + description: > + 202 ACCEPTED + + Shall be returned when the API producer has chosen the asynchronous mode + and the + + request has been accepted for processing. + + The response body shall be empty. + + The HTTP response shall include a "Location" HTTP header that indicates + the URI of + + the "Individual coordination action" resource that will be created once + the + + coordination operation has finished successfully. + + Further, the HTTP response may include a "Retry-After" HTTP header that + indicates the + + time to wait before sending the next GET request to the "individual + coordination" resource + + indicated in the "Location" header. If the header is provided, the VNFM + shall record the signalled + + delay value in the "delay" attribute of the applicable entry in the + "lcmCoordinations" array in the + + "VnfLcmOpOcc" structure. + headers: + Version: + description: | + The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: > + Used in redirection, or when a new resource has been created. This + header field shall be present if the + + response status code is 201 or 3xx. In the present document this + header field is also used if the response + + status code is 202 and a new resource was created. + style: simple + explode: false + schema: + type: string + format: url + content: {} + Coordination.Post.403: + description: > + 403 FORBIDDEN + + Shall be returned upon the following error: The starting of the + coordination operation has been rejected. No "individual coordination + action" resource shall be created. A ProblemDetails structure shall be + included in the response to provide more details about the rejection in + the "details" attribute. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + Coordination.Post.409: + description: > + 409 CONFLICT + + Shall be returned upon the following error: The operation cannot be + executed currently, due to a conflict with the state of the + "Coordinations" resource. Typically, this is due to the fact that no + more coordination actions can be executed currently e.g. because too + many of them, or conflicting ones, are in progress. The response body + shall 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. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + Coordination.Post.503: + description: > + 503 SERVICE UNAVAILABLE + + Shall be returned upon the following error: The API producer has chosen + the synchronous mode and cannot perform the requested coordination + currently, but expects to be able to perform it sometime in the future. + No "individual coordination action" resource shall be created. A + ProblemDetails structure shall be included in the response to provide + more details about the rejection in the "details" attribute. The HTTP + response shall include a "Retry-After" HTTP header that indicates the + delay after which it is suggested to repeat the coordination request + with the same set of parameters. The VNFM shall record the signalled + delay value in the "delay" attribute of the applicable entry in the + "rejectedLcmCoordinations" array in the "VnfLcmOpOcc" structure. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + LcmCoord.Get.200: + description: > + 200 OK + + Shall be returned when the coordination is finished and the coordination + result has been read successfully. + + A representation of the "Individual coordination action" resource shall + be returned in the response body. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: | + This type represents an LCM coordination result. + type: object + required: + - id + - coordinationResult + - vnfInstanceId + - vnfLcmOpOccId + - lcmOperationType + - coordinationActionName + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + coordinationResult: + description: > + The enumeration LcmCoordResultType defines the permitted + values to represent the result of executing an LCM + coordination action. The coordination result also implies the + action to be performed by the VNFM as the follow-up to this + coordination. Value | Description ------|------------ CONTINUE + | The related LCM operation shall be continued, staying in the + state "PROCESSING". ABORT | The related LCM operation shall be + aborted by transitioning into the state "FAILED_TEMP". + CANCELLED | The coordination action has been cancelled upon + request of the API consumer, i.e. the VNFM. The related LCM + operation shall be aborted by transitioning into the state + "FAILED_TEMP". + type: string + enum: + - CONTINUE + - ABORT + - CANCELLED + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfLcmOpOccId: + description: | + An identifier with the intention of being globally unique. + type: string + lcmOperationType: + description: > + The enumeration LcmOperationForCoordType defines the permitted + values to represent VNF lifecycle operation types in VNF LCM + operation coordination actions. * INSTANTIATE: Represents the + "Instantiate VNF" LCM operation. * SCALE: Represents the + "Scale VNF" LCM operation. * SCALE_TO_LEVEL: Represents the + "Scale VNF to Level" LCM operation. * CHANGE_FLAVOUR: + Represents the "Change VNF Flavour" LCM operation. * + TERMINATE: Represents the "Terminate VNF" LCM operation. * + HEAL: Represents the "Heal VNF" LCM operation. * OPERATE: + Represents the "Operate VNF" LCM operation. * CHANGE_EXT_CONN: + Represents the "Change external VNF connectivity" LCM + operation. * MODIFY_INFO: Represents the "Modify VNF + Information" LCM operation. * CREATE_SNAPSHOT: Represents the + "Create VNF Snapshot" LCM operation. * REVERT_TO_SNAPSHOT: + Represents the "Revert To VNF Snapshot" LCM operation. * + CHANGE_VNFPKG: Represents the "Change current VNF package" LCM + operation. + type: string + enum: + - INSTANTIATE + - SCALE + - SCALE_TO_LEVEL + - CHANGE_FLAVOUR + - TERMINATE + - HEAL + - OPERATE + - CHANGE_EXT_CONN + - MODIFY_INFO + - CREATE_SNAPSHOT + - REVERT_TO_SNAPSHOT + - CHANGE_VNFPKG + coordinationActionName: + description: > + Indicates the actual LCM coordination action. The coordination + actions that a VNF supports are declared in the VNFD. + type: string + outputParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + warnings: + description: > + Warning messages that were generated while the operation was + executing. + type: string + error: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + - vnfLcmOpOcc + - vnfInstance + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfLcmOpOcc: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + LcmCoord.Get.202: + description: > + 202 ACCEPTED + + Shall be returned when the management operation with which coordination + is requested is still ongoing or + + in the process of being cancelled, i.e. no coordination result is + available yet. + + The response shall be empty. + headers: + Version: + description: | + The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: > + Used in redirection, or when a new resource has been created. This + header field shall be present if the + + response status code is 201 or 3xx. In the present document this + header field is also used if the response + + status code is 202 and a new resource was created. + style: simple + explode: false + schema: + type: string + format: url + content: {} + CoordinationCancel.Post.202: + description: > + 202 ACCEPTED + + Shall be returned when the cancellation request has been accepted for + processing. + + The response shall have an empty message content. + headers: + Version: + description: | + The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: > + Used in redirection, or when a new resource has been created. This + header field shall be present if the + + response status code is 201 or 3xx. In the present document this + header field is also used if the response + + status code is 202 and a new resource was created. + style: simple + explode: false + schema: + type: string + format: url + content: {} + CoordinationCancel.Post.409: + description: > + 409 CONFLICT + + Shall be returned upon the following error: The operation cannot be + executed currently, due to a conflict with the state of the "Individual + coordination action" resource. Typically, this is due to the fact that + the coordination action has finished processing. The response body shall + contain a ProblemDetails structure, in which the "detail" attribute + shall convey more information about the error. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + diff --git a/v5.3.1/SOL002-VNFLifecycleManagement-API.json b/v5.3.1/SOL002-VNFLifecycleManagement-API.json new file mode 100644 index 00000000..1c817214 --- /dev/null +++ b/v5.3.1/SOL002-VNFLifecycleManagement-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL002 - VNF Lifecycle Management interface","description":"SOL002 - VNF Lifecycle Management interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"2.16.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 002 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/05.03.01_60/gs_NFV-SOL002v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/vnflcm/v2"},{"url":"https://127.0.0.1/vnflcm/v2"}],"paths":{"/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method queries information about multiple VNF instances. See clause 5.4.2.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"$ref":"#/components/parameters/filter_vnf_instances"},{"name":"all_fields","description":"Include all complex attributes in the response. See clause 5.3 of ETSI GS NFV-SOL 013 [6] for details. The VNFM shall support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"fields","description":"Complex attributes to be included into the response. See clause 5.3 of ETSI GS NFV-SOL 013 [6] for details. The VNFM should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"exclude_fields","description":"Complex attributes to be excluded from the response. See clause 5.3 of ETSI GS NFV-SOL 013 [6] for details. The VNFM should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"$ref":"#/components/parameters/exclude_default_vnf_instances"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [6] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/VnfInstances.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"The POST method creates a new VNF instance resource based on a VNF package that is onboarded and in \"ENABLED\" state.\nSee clause 5.4.2.3.1.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/VnfInstanceCreationRequest"},"responses":{"201":{"$ref":"#/components/responses/VnfInstances.Post.201"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/VnfInstances.Post.422"},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"Information about a VNF instance by reading an \"Individual VNF instance\". See clause 5.4.3.3.2.\n","responses":{"200":{"$ref":"#/components/responses/IndividualVnfInstance.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method deletes an \"Individual VNF instance\" resource. See clause 5.4.3.3.5.\n","responses":{"204":{"$ref":"#/components/responses/IndividualVnfInstance.Delete.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/IndividualVnfInstance.Delete.409"},"422":{"description":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method modifies an \"Individual VNF instance\" resource. See clause 5.4.3.3.4.\n","parameters":[{"name":"If-Unmodified-Since","description":"Used to make the request method conditional on the selected resource representation's last modification date being earlier than or equal to the date provided in the field-value. If the condition is not met, the request fails with a \"412 Precondition Failed\" response.\n","required":false,"in":"header","schema":{"type":"string","format":"date-time"}},{"name":"If-Match","description":"Used to make the request method conditional on the recipient origin server either having at least one current representation of the target resource, when the field-value is \"*\", or having a current representation of the target resource that has an entity-tag matching a member of the list of entity-tags provided in the field-value. If the condition is not met, the request fails with a \"412 Precondition Failed\" response.\n","required":false,"in":"header","schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/VnfInstanceModificationRequest"},"responses":{"202":{"$ref":"#/components/responses/IndividualVnfInstance.Patch.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/IndividualVnfInstance.Patch.409"},"412":{"description":"412 PRECONDITION FAILED\nError: 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/select_depl_mods":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"The POST method requests to select deployable modules of a VNF instance. See clause 5.4.11b.3.1\n","requestBody":{"$ref":"#/components/requestBodies/SelectVnfDeployableModulesRequest"},"responses":{"202":{"$ref":"#/components/responses/Selectdeployablemodules.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"409 CONFLICT\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/instantiate":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"The POST method instantiates a VNF instance. See clause 5.4.4.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/VnfInstanceInstantiationRequest"},"responses":{"202":{"$ref":"#/components/responses/InstantiateVnfInstance.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/InstantiateVnfInstance.Post.409"},"422":{"description":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/scale":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"The POST method requests to scale a VNF instance resource incrementally. See clause 5.4.5.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/VnfInstanceScaleRequest"},"responses":{"202":{"$ref":"#/components/responses/ScaleVnfInstance.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/ScaleVnfInstance.Post.409"},"422":{"description":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/scale_to_level":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"The POST method requests to scale a VNF instance resource to a target level. See clause 5.4.6.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/VnfInstanceScaleToLevelRequest"},"responses":{"202":{"$ref":"#/components/responses/ScaleVnfInstanceToLevel.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/ScaleVnfInstanceToLevel.Post.409"},"422":{"description":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/change_flavour":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"The POST method changes the deployment flavour of a VNF instance. See clause 5.4.7.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/VnfInstanceChangeFlavourRequest"},"responses":{"202":{"$ref":"#/components/responses/VnfInstanceChangeFlavour.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/VnfInstanceChangeFlavour.Post.409"},"422":{"description":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/terminate":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"The POST method triggers the VNFM to terminate a VNF instance and to request to the VIM the release of its\nused virtualised resources. See clause 5.4.8.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/VnfInstanceTerminationRequest"},"responses":{"202":{"$ref":"#/components/responses/TerminateVnfInstance.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/TerminateVnfInstance.Post.409"},"422":{"description":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/heal":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"The POST method requests to heal a VNF instance. See clause 5.4.9.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/VnfInstanceHealRequest"},"responses":{"202":{"$ref":"#/components/responses/HealVnfInstance.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/HealVnfInstance.Post.409"},"422":{"description":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/operate":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"The POST method changes the operational state of a VNF instance. See clause 5.4.10.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/VnfInstanceOperateRequest"},"responses":{"202":{"$ref":"#/components/responses/OperateVnfInstance.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/OperateVnfInstance.Post.409"},"422":{"description":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/change_ext_conn":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"The POST method changes the external connectivity of a VNF instance. See clause 5.4.11.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/VnfInstanceChangeExtConnRequest"},"responses":{"202":{"$ref":"#/components/responses/VnfInstanceChangeExtConn.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/VnfInstanceChangeExtConn.Post.409"},"422":{"description":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/change_vnfpkg":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"The POST method changes the current VNF package on which the VNF instance is based.\nSee clause 5.4.11a.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/VnfInstanceChangeVnfPkgRequest"},"responses":{"202":{"$ref":"#/components/responses/VnfInstanceChangeVnfPkg.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/VnfInstanceChangeVnfPkg.Post.409"},"422":{"description":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_lcm_op_occs":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The client can use this method to query status information about multiple VNF lifecycle\nmanagement operation occurrences. See clause 5.4.12.3.2.\n","parameters":[{"$ref":"#/components/parameters/filter_vnf_lcm_op_occs"},{"name":"all_fields","description":"Include all complex attributes in the response. See clause 5.3 of ETSI GS NFV-SOL 013 [6] for details. The VNFM shall support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"fields","description":"Complex attributes to be included into the response. See clause 5.3 of ETSI GS NFV-SOL 013 [6] for details. The VNFM should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"exclude_fields","description":"Complex attributes to be excluded from the response. See clause 5.3 of ETSI GS NFV-SOL 013 [6] for details. The VNFM should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"$ref":"#/components/parameters/exclude_default_vnf_lcm_op_occs"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [6] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/VnfLcmOpOccs.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_lcm_op_occs/{vnfLcmOpOccId}":{"parameters":[{"$ref":"#/components/parameters/VnfLcmOpOccId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The client can use this method to retrieve status information about a VNF lifecycle management operation occurrence\nby reading an \"Individual VNF LCM operation occurrence\" resource. See clause 5.4.13.3.2.\n","responses":{"200":{"$ref":"#/components/responses/IndividualVnfLcmOpOcc.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_lcm_op_occs/{vnfLcmOpOccId}/retry":{"parameters":[{"$ref":"#/components/parameters/VnfLcmOpOccId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"The POST method initiates retrying a VNF lifecycle operation if that operation has experienced a temporary\nfailure, i.e. the related \"Individual VNF LCM operation occurrence\" resource is in \"FAILED_TEMP\" state.\nSee clause 5.4.14.3.1.\n","responses":{"202":{"$ref":"#/components/responses/VnfLcmOpOccRetry.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/VnfLcmOpOccRetry.Post.409"},"422":{"description":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_lcm_op_occs/{vnfLcmOpOccId}/rollback":{"parameters":[{"$ref":"#/components/parameters/VnfLcmOpOccId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"The POST method initiates rolling back a VNF lifecycle operation if that operation has experienced a temporary\nfailure, i.e. the related \"Individual VNF LCM operation occurrence\" resource is in \"FAILED_TEMP\" state.\nSee clause 5.4.15.3.1.\n","responses":{"202":{"$ref":"#/components/responses/VnfLcmOpOccRollback.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/VnfLcmOpOccRollback.Post.409"},"422":{"description":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_lcm_op_occs/{vnfLcmOpOccId}/fail":{"parameters":[{"$ref":"#/components/parameters/VnfLcmOpOccId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"The POST method marks a VNF lifecycle management operation occurrence as \"finally failed\" if that operation\noccurrence is in \"FAILED_TEMP\" state. See clause 5.4.16.3.1.\n","responses":{"200":{"$ref":"#/components/responses/VnfLcmOpOccFail.Post.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/VnfLcmOpOccFail.Post.409"},"422":{"description":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_lcm_op_occs/{vnfLcmOpOccId}/cancel":{"parameters":[{"$ref":"#/components/parameters/VnfLcmOpOccId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"The POST method initiates cancelling an ongoing VNF lifecycle operation while it is being executed or rolled\nback, i.e. the related \"Individual VNF LCM operation occurrence\" is either in \"PROCESSING\" or \"ROLLING_BACK\" state.\nSee clause 5.4.17.3.1.\n","responses":{"202":{"$ref":"#/components/responses/VnfLcmOpOccCancel.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/VnfLcmOpOccCancel.Post.409"},"422":{"description":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/subscriptions":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method queries the list of active subscriptions of the functional block that invokes the method. It can\nbe used e.g. for resynchronization after error situations. See clause 5.4.18.3.2.\n","parameters":[{"$ref":"#/components/parameters/filter_subscriptions"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [6] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/Subscriptions.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"The POST method creates a new subscription. See clause 5.4.18.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/VnfLcmSubscriptionRequest"},"responses":{"201":{"$ref":"#/components/responses/Subscriptions.Post.201"},"303":{"description":"303 See Other\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/Subscriptions.Post.422"},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/subscriptions/{subscriptionId}":{"parameters":[{"$ref":"#/components/parameters/SubscriptionId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method retrieves information about a subscription by reading an \"Individual subscription\" resource.\nSee clause 5.4.19.3.2.\n","responses":{"200":{"$ref":"#/components/responses/IndividualSubscription.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"The DELETE method terminates an individual subscription. See clause 5.4.19.3.5.\n","responses":{"204":{"$ref":"#/components/responses/IndividualSubscription.Delete.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/create_snapshot":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"The POST method requests tacking a VNF instance snapshot and populating a previously created VNF snapshot resource\n(refer to clause 5.4.23.3.1) with the snapshot content. See clause 5.4.21.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/VnfInstanceCreateSnapshotRequest"},"responses":{"202":{"$ref":"#/components/responses/VnfInstanceCreateSnapshot.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/VnfInstanceCreateSnapshot.Post.404"},"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/VnfInstanceCreateSnapshot.Post.409"},"422":{"$ref":"#/components/responses/VnfInstanceCreateSnapshot.Post.422"},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/revert_to_snapshot":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"The POST method requests reverting a VNF/VNFC instance to a VNF/VNFC snapshot. See clause 5.4.22.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/VnfInstanceRevertToSnapshotRequest"},"responses":{"202":{"$ref":"#/components/responses/VnfInstanceRevertToSnapshot.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/VnfInstanceRevertToSnapshot.Post.409"},"422":{"description":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_snapshots":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"The POST method creates a new individual VNF snapshot resource. See clause 5.4.23.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/VnfSnapshotsRequest"},"responses":{"201":{"$ref":"#/components/responses/VnfSnapshots.Post.201"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"409 CONFLICT\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"get":{"description":"The GET method queries information about multiple VNF/VNFC snapshots. See clause 5.4.23.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"$ref":"#/components/parameters/filter_vnf_snapshots"},{"name":"all_fields","description":"Include all complex attributes in the response. See clause 5.3 of ETSI GS NFV-SOL 013 [6] for details. The VNFM shall support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"fields","description":"Complex attributes to be included into the response. See clause 5.3 of ETSI GS NFV-SOL 013 [6] for details. The VNFM should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"exclude_fields","description":"Complex attributes to be excluded from the response. See clause 5.3 of ETSI GS NFV-SOL 013 [6] for details. The VNFM should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"$ref":"#/components/parameters/exclude_default_vnf_snapshots"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [6] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/VnfSnapshots.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_snapshots/{vnfSnapshotInfoId}":{"parameters":[{"$ref":"#/components/parameters/VnfSnapshotInfoId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method retrieves information about a VNF /VNFC snapshot by reading an individual VNF snapshot resource.\nSee clause 5.4.24.3.2.\n","responses":{"200":{"$ref":"#/components/responses/IndividualVnfSnapshot.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method deletes an individual VNF snapshot resource and the associated VNF snapshot information managed by\nthe VNFM, and any resource associated to the VNF/VNFC snapshot managed by the VIM. See clause 5.4.24.3.5.\n","responses":{"204":{"$ref":"#/components/responses/IndividualVnfSnapshot.Delete.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/IndividualVnfSnapshot.Delete.409"},"422":{"description":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"parameters":{"filter_vnf_snapshots":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013. The VNFM shall support receiving this parameter as part of the URI query string. The EM may supply this parameter. All attribute names that appear in the VnfSnapshot and in data types referenced from it shall be supported by the VNFM in the filter expression.\n","in":"query","required":false,"schema":{"type":"string"}},"exclude_default_vnf_snapshots":{"name":"exclude_default","in":"query","description":"Indicates to exclude the following complex attributes from the response. See clause 5.3 of ETSI GS NFV-SOL 013 for details. The VNFM shall support this parameter. The following attributes shall be excluded from the VnfSnapshot structure in the response body if this parameter is provided, or none of the parameters \"all_fields,\" \"fields\", \"exclude_fields\", \"exclude_default\" are provided: - vnfInstance\n - vnfcSnapshots","required":false,"schema":{"type":"string"}},"filter_subscriptions":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013. The VNFM shall support receiving this parameter as part of the URI query string. The EM may supply this parameter. All attribute names that appear in the LccnSubscription and in data types referenced from it shall be supported by the VNFM in the filter expression.\n","in":"query","required":false,"schema":{"type":"string"}},"filter_vnf_lcm_op_occs":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013. The VNFM shall support receiving this parameter as part of the URI query string. The EM/VNF may supply this parameter. All attribute names that appear in the VnfLcmOpOcc and in data types referenced from it shall be supported by the VNFM in the filter expression.\n","in":"query","required":false,"schema":{"type":"string"}},"exclude_default_vnf_lcm_op_occs":{"name":"exclude_default","in":"query","description":"Indicates to exclude the following complex attributes from the response. See clause 5.3 of ETSI GS NFV-SOL 013 for details. The VNFM shall support this parameter. The following attributes shall be excluded from the VnfLcmOpOcc structure in the response body if this parameter is provided, or none of the parameters \"all_fields\", \"fields\", \"exclude_fields\", \"exclude_default\" are provided: - operationParams\n - error\n - resourceChanges\n - changedInfo\n - changedExtConnectivity\n - lcmCoordinations\n - modificationsTriggeredByVnfPkgChange\n - warnings\n","required":false,"schema":{"type":"string"}},"filter_vnf_instances":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013. The VNFM shall support receiving this parameter as part of the URI query string. The EM may supply this parameter. All attribute names that appear in the VnfInstance and in data types referenced from it shall be supported by the VNFM in the filter expression.\n","in":"query","required":false,"schema":{"type":"string"}},"exclude_default_vnf_instances":{"name":"exclude_default","in":"query","description":"Indicates to exclude the following complex attributes from the response. See clause 5.3 of ETSI GS NFV-SOL 013 for details. The VNFM shall support this parameter. The following attributes shall be excluded from the VnfInstance structure in the response body if this parameter is provided, or none of the parameters \"all_fields\", \"fields\", \"exclude_fields\", \"exclude_default\" are provided: - vnfConfigurableProperties\n - instantiatedVnfInfo\n - metadata\n - extensions","required":false,"schema":{"type":"string"}},"VnfInstanceId":{"name":"vnfInstanceId","in":"path","description":"Identifier of the VNF instance. This identifier can be retrieved from the resource referenced by the \"Location\"\nHTTP header in the response to a POST request creating a new VNF instance resource. It can also be retrieved\nfrom the \"id\" attribute in the message content of that response.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"VnfLcmOpOccId":{"name":"vnfLcmOpOccId","in":"path","description":"Identifier of a VNF lifecycle management operation occurrence. This identifier can be retrieved from the resource\nreferenced by the \"Location\" HTTP header in the response to a PATCH or POST request triggering a VNF LCM operation.\nIt can also be retrieved from the \"vnfLcmOpOccId\" attribute in the VnfLcmOperationOccurrenceNotification.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"SubscriptionId":{"name":"subscriptionId","in":"path","description":"Identifier of this subscription. This identifier can be retrieved from the resource referenced by the \"Location\"\nHTTP header in the response to a POST request creating a new subscription resource. It can also be retrieved from\nthe \"id\" attribute in the message content of that response.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"VnfSnapshotInfoId":{"name":"vnfSnapshotInfoId","in":"path","description":"Identifier of the individual VNF snapshot resource. This identifier can be retrieved from the resource referenced by the\n\"Location\" HTTP header in the response to a POST request creating a new VNF snapshot resource. It can also be\nretrieved from the \"id\" attribute in the message content of that response.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}}},"requestBodies":{"VnfInstanceCreationRequest":{"description":"The VNF creation parameters, as defined in clause 5.5.2.3.\n","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Create VNF identifier\" operation.\n","type":"object","required":["vnfdId"],"properties":{"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceName":{"description":"Human-readable name of the VNF instance to be created.\n","type":"string"},"vnfInstanceDescription":{"description":"Human-readable description of the VNF instance to be created.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateConfigurationData":{"description":"This type provides input information related to certificate management.\n","type":"object","required":["securityPolicy"],"properties":{"overridingCertificateProfile":{"description":"Overriding certificate profile. This overrides the certificateBaseProfile provided in the VNFD, and the CA and CMF can additionally override aspects of this certificateBaseProfile at later point in the VNF lifecycle if necessary to meet operator security policy.\n","type":"array","items":{"description":"This type provides input information to override certificate base profile for certificate management\nNOTE : At least one overriding attributes shall be present, otherwise shall be absent.\n","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"type":"string","description":"Issuer of certificates. See note."},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to subject of certificate.\n* NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of certification target subject FQDN. See note.","type":"string"},"organization":{"description":"Information of certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of certification target subject Country. See note.","type":"string"},"state":{"description":"Information of certification target subject State. See note.","type":"string"},"locality":{"description":"Information of certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"type":"string","description":"Basic constraints of certificates. See note.\n"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [7],clause 7.1.19.4). See note","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}}},"securityPolicy":{"description":"Security policy to be satisfied for certificate.\n","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"integer"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"integer"}}}},"cmfData":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["endPoint","supportedProtocol"],"properties":{"endPoint":{"description":"End point of CMF instance.","type":"object","required":["ipAddress","link"],"properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocol":{"description":"Supported protocols by CMF instance.","type":"array","items":{"type":"string","enum":["CMP","CMPv2","EST","SCEP"]}}}}}}}}}},"required":true},"VnfInstanceModificationRequest":{"description":"Input parameters for VNF info modification","content":{"application/merge-patch+json":{"schema":{"description":"This type represents attribute modifications for an \"Individual VNF instance\" resource, i.e. modifications to a resource representation based on the \"VnfInstance\" data type. The attributes of \"VnfInstance\" that can be modified according to the provisions in clause 5.5.2.2 are included in the \"VnfInfoModificationRequest\" data type.\n","type":"object","properties":{"vnfInstanceName":{"description":"New value of the \"vnfInstanceName\" attribute in \"VnfInstance\", or \"null\" to remove the attribute.\n","type":"string"},"vnfInstanceDescription":{"description":"New value of the \"vnfInstanceDescription\" attribute in \"VnfInstance\", or \"null\" to remove the attribute.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vnfcInfoModifications":{"description":"Modifications of certain entries in the \"vnfcInfo\" attribute array in the \"instantiatedVnfInfo\" attribute of \"VnfInstance\" to be used as \"newList\" as defined below this table. The following provisions shall apply when modifying an attribute that is an array of objects of type \"VnfcInfo\" by supplying an array of objects of type \"VnfcInfoModifications\". Assumptions: 1) \"oldList\" is the \"VnfcInfo\" array to be modified and \"newList\" is the \"VnfcInfoModifications\" array that contains the changes.\n2) \"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 \"id\" attribute as the \"newEntry\"; a \"newEntry\" has no corresponding entry if no such \"oldEntry\" exists.\n4) In any array of \"VnfcInfo\" resp. \"VnfcInfoModifications\" structures, the content of \"id\" is unique (i.e. there are no two entries with the same content of \"id\").\nProvisions: 1) For each \"newEntry\" in \"newList\" that has no corresponding entry in \"oldList\", the \"oldList\" array shall be modified by adding that \"newEntry\".\n2) For each \"newEntry\" in \"newList\" that has a corresponding \"oldEntry\" in \"oldList\", the value of \"oldEntry\" shall be updated with the content of \"newEntry\" as specified for\n the data type of \"newEntry (refer to clause 5.5.3.24 for the data type \"VnfcInfoModifications\").\n","type":"array","items":{"description":"This type represents modifications of an entry in an array of \"VnfcInfo\" objects. * NOTE:\tThe attribute \"id\" in this data type represents the same identifier as the attribute\n \"vnfcInstanceId\" in other related data types in the present document. For reasons of backward\n compatibility, this misalignment is not corrected.\n","type":"object","required":["id","vnfcConfigurableProperties"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}}}},"required":true},"VnfInstanceInstantiationRequest":{"description":"Parameters for the VNF instantiation.","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Instantiate VNF\" operation. * NOTE 1: The indication of externally-managed internal VLs is needed in case networks have been pre-configured for use with certain VNFs, for instance to ensure that these networks have certain\n properties such as security or acceleration features, or to address particular network topologies.\n The present document assumes that externally-managed internal VLs are managed by the NFVO and\n created towards the VIM.\n NOTE 2: The target size for VNF instantiation may be specified in either instantiationLevelId or targetScaleLevelInfo, \n but not both. If none of the two attributes (instantiationLevelId or targetScaleLevelInfo) are \n present, the default instantiation level as declared in the VNFD shall be used.\n NOTE 3: If targetScaleLevelInfo is specified, information provided in targetScaleLevelInfo shall be used for \n instantiating scalable constituents of the VNF (e.g, VDUs/VLs). For scaling aspects not specified in \n targetScaleLevelInfo or for the VNF constituents (e.g., VDUs/VLs) that are not scalable, the default \n instantiation level as declared in the VNFD shall be used for instantiation. \n NOTE 4: If the referenced instantiationLevel or the targetScaleLevelInfo contain information related to VNFCs that are\n not going to be instantiated due to the selection of deployable modules, the information is stored in the VNFM\n for later use and included in the instantiatedVnfInfo. If none of the attributes is present, the information from the\n defaultInstantiationLevel related to those VNFCs is stored and included in the instantiatedVnfInfo. If, during the\n lifecycle of the VNF, as a result of a change of the selected deployable modules any of those VNFCs is going to\n be instantiated, the stored information determines the number of instances, unless the request that triggered\n the change also contains information about the number of instances.\n","type":"object","required":["flavourId"],"properties":{"flavourId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"instantiationLevelId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"targetScaleLevelInfo":{"description":"This attribute is applicable if VNF supports target scale level instantiation. For each scaling aspect of the current deployment flavour, the attribute specifies the scale level of VNF constituents (e.g., VDU level) to be instantiated. See notes 2 3, and 4.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleLevel":{"description":"Indicates the scale level. The minimum value shall be 0 and the maximum value shall be <= maxScaleLevel as described in the VNFD.\n","type":"integer"}}}},"extVirtualLinks":{"description":"Information about external VLs to connect the VNF to, including configuration information for the CPs via which the VNF instance can attach to this VL. The following applies to the \"ExtVirtualLinkData\" information provided in this request: Even if the VNF is not instantiated in fully scaled-out state, the API consumer shall provide enough CP configuration records to allow connecting the VNF instance, fully scaled out in all scaling aspects, to the external VLs.\n","type":"array","items":{"description":"This type represents an external VL. * NOTE 1: The information about the VIM connection referenced by the VIM connection id is known to the VNFM. \n Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2:\t A link port is not needed for an external CP instance that exposes a CP in the following cases:\n 1) For a virtual IP CP directly exposed as an external CP:\n 1.1) No dedicated IP address is allocated as virtual IP address, as indicated in the VNFD.\n 1.2) A dedicated IP address is allocated as virtual IP address, but the NFVO indicates that no port is\n needed (createExtLinkPort in VnfExtCpconfig set to false).\n 2) For a virtual IP CP exposed as an external CP via a floating IP address:\n 2.1) No dedicated IP address is allocated as virtual IP address, as indicated in the VNFD, and the VNFC\n CP associated to the virtual IP CP is also exposed via a floating IP address.\n 3) For a VIRTUAL CP exposed as an external CP.\n 4) For a VNFC CP exposed as an external CP in a secondary container cluster external network.\n\n* NOTE 3: An example of the network attachment definition resource when the container infrastructure service\n management is a Kubernetes® instance is a network attachment definition (NAD).\n\n* NOTE 4: Either \"extCps\" or “extCpsDeletion\" shall be present, but not both.\n","type":"object","required":["id","resourceId"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"extCps":{"description":"External CPs of the VNF to be connected to this external VL. Entries in the list of external CP data that are unchanged need not be supplied if the ExtVirtualLinkData structure is part of a request or response that modifies the external connectivity.See note 4.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD. The key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO. The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5 and 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored.\n\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for \n Kubernetes® that supports configuration of address pools for load balancer services.\n\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"string"},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"string"}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}}}}},"extLinkPorts":{"description":"Externally provided link ports to be used to connect external connection points to this external VL. If this attribute is not present, the VNFM shall create the link ports on the external VL except in the cases defined below. See note 2.\n","type":"array","items":{"description":"This type represents an externally provided link port to be used to connect an external connection point to an external VL. * NOTE:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"extNetAttDefResourceData":{"description":"Externally provided network attachment definition resource(s) that provide the specification of the interface to attach external CPs to this external VL. See note 3. It is only applicable if the external VL is realized by a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"This type represents a network attachment definition resource that provides the specification of the interface to be used to connect one or multiple connection points to a secondary container cluster network realizing a VL.\n","type":"object","required":["netAttDefResourceId","resourceHandle"],"properties":{"netAttDefResourceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"extCpsDeletion":{"description":"External CPs of the VNF to be disconnected from this external VL and to be deleted. See note 4.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD. The key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO. The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5 and 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored.\n\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for \n Kubernetes® that supports configuration of address pools for load balancer services.\n\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"string"},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"string"}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}}}}}}}},"extManagedVirtualLinks":{"description":"Information about external VLs to connect the VNF to. See note 1.\n","type":"array","items":{"description":"This type represents an externally-managed internal VL. * NOTE:\tThe information about the VIM connection referenced by the VIM connection id is known to the VNFM.\n Moreover, the identifier of the VIM connection provides scope to the resourceId.\n","type":"object","required":["id","virtualLinkDescId","resourceId"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"localizationLanguage":{"description":"Localization language of the VNF to be instantiated. The value shall comply with the format defined in IETF RFC 5646.\n","type":"string"},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"selectedDeployableModule":{"description":"Identifier of a selected deployable module. Only VNFCs based on VDUs that belong to deployable modules listed in this attribute are requested to be instantiated.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceCapacityDefinition":{"description":"Indicates values for resource capacity related attributes pertaining to a descriptor. Values can only be provided for resource capacity related attributes that have been defined in the VNFD as being configurable. Furthermore, provided values shall be within the allowed values indicated in the VNFD.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes. The tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request. At most one tag can be included when the data type is used in a VNF LCM operation request. When the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced. VALUES •\tCOMPUTE •\tSTORAGE •\tOSCONTAINER","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute ‘type’ indicates OSCONTAINER and absent otherwise.","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource.See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resources_property in the VNFD that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["resourceTemplateId"]},{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD for this virtual compute descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}}}}}},"required":true},"SelectVnfDeployableModulesRequest":{"description":"Parameters for the VNF deployable modules selection.","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Select VNF deployable modules\" operation. * NOTE 1: Thus, the select VNF deployable modules operation cannot be used as a scale VNF operation to horizontally scale VNFCs that were already instantiated.\n* NOTE 2: Thus, the select VNF deployable modules operation cannot be used as a scale VNF operation to vertically scale VNFCs that were already instantiated.\n","type":"object","properties":{"selectedDeployableModule":{"description":"Identifier of a selected deployable module, as defined in the VNFD. VNFCs based on VDUs that belong to deployable modules listed in this attribute will be instantiated if not already instantiated. VNFCs based on VDUs that belong to deployable modules not listed in this attribute and that were already instantiated will be terminated.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"targetScaleLevelInfo":{"description":"Defines the target scale levels of scaling aspects of the VDUs that belong to selected deployable modules. If this attribute is not present or if there are VDUs that belong to selected deployable modules that take no part in any of the scaling aspects indicated in this attribute, the VNFCs based on those VDUs shall be instantiated according to the currently valid VNF scale level or instantiation level. This attribute should only contain scale level information of scaling aspects associated to VDUs that will be used to instantiate VNFCs as a result of this operation. If it contains other scale level information it shall be ignored. See note. The VNF Provider defines in the VNFD whether or not a particular VNF supports scaling according to this parameter. Such a property in the VNFD applies for all instances of a particular VNF.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleLevel":{"description":"Indicates the scale level. The minimum value shall be 0 and the maximum value shall be <= maxScaleLevel as described in the VNFD.\n","type":"integer"}}}},"resourceCapacityDefinition":{"description":"Indicates values for resource capacity related attributes pertaining to a descriptor. Values can only be provided for resource capacity related attributes that have been defined in the VNFD as being configurable. Furthermore, provided values shall be within the allowed values indicated in the VNFD. This attribute should only contain information about resource capacity related attributes of VDUs that will be used to instantiate VNFCs as a result of this operation. If it contains information about attributes of other VDUs it shall be ignored. See note 2.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes. The tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request. At most one tag can be included when the data type is used in a VNF LCM operation request. When the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced. VALUES •\tCOMPUTE •\tSTORAGE •\tOSCONTAINER","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute ‘type’ indicates OSCONTAINER and absent otherwise.","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource.See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resources_property in the VNFD that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["resourceTemplateId"]},{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD for this virtual compute descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"required":true},"VnfInstanceScaleRequest":{"description":"Parameters for the scale VNF operation.","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Scale VNF\" operation.\n","type":"object","required":["type"],"properties":{"type":{"description":"Indicates the type of the scale operation requested. Permitted values: * SCALE_OUT: adding additional VNFC instances to the VNF to increase capacity\n* SCALE_IN: removing VNFC instances from the VNF in order to release unused capacity.\n* SCALE_VERTICAL: increasing or decreasing the resource capacity of all instances of one or multiple VNFCs.\n","type":"string","enum":["SCALE_OUT","SCALE_IN","SCALE_VERTICAL"]},"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numberOfSteps":{"description":"Number of scaling steps to be executed as part of this Scale VNF operation. It shall be a positive number and the default value shall be 1.\n","type":"integer","default":1},"resourceCapacityDefinition":{"description":"Indicates values for resource capacity related attributes pertaining to a descriptor. The indicated values are absolute (target) values, as opposed to relative (delta) values. Values can only be provided for resource capacity related attributes that have been defined in the VNFD as being configurable. Furthermore, provided values shall be within the allowed values indicated in the VNFD. It shall be present when ‘type’ indicates SCALE_VERTICAL and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes. The tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request. At most one tag can be included when the data type is used in a VNF LCM operation request. When the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced. VALUES •\tCOMPUTE •\tSTORAGE •\tOSCONTAINER","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute ‘type’ indicates OSCONTAINER and absent otherwise.","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource.See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resources_property in the VNFD that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["resourceTemplateId"]},{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD for this virtual compute descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"required":true},"VnfInstanceScaleToLevelRequest":{"description":"Parameters for the scale VNF to Level operation.","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Scale VNF to Level\" operation.\nNOTE 1:\tEither the instantiationLevelId attribute or the scaleInfo attribute or the powerProfileId attribute shall \n be included, but not multiple of them.\nNOTE 2: If the referenced instantiationLevel, the scaleInfo or powerProfileId attribute contain information related to VNFCs\n that are not going to be instantiated due to the selection of deployable modules, the information is stored in the \n VNFM for later use and included in the instantiatedVnfInfo. If, during the lifecycle of the VNF, as a result of \n a change of the selected deployable modules any of those VNFCs is going to be instantiated, the stored information\n determines the number of instances, unless the request that triggered the change also contains information\n about the number of instances.\n","type":"object","anyOf":[{"oneOf":[{"required":["instantiationLevelId"]},{"required":["scaleInfo"]},{"required":["powerProfileId"]}]}],"properties":{"instantiationLevelId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"scaleInfo":{"description":"For each scaling aspect of the current deployment flavour, indicates the target scale level to which the VNF is to be scaled. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleLevel":{"description":"Indicates the scale level. The minimum value shall be 0 and the maximum value shall be <= maxScaleLevel as described in the VNFD.\n","type":"integer"}}}},"powerProfileId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"required":true},"VnfInstanceChangeFlavourRequest":{"description":"Parameters for the Change VNF Flavour operation.","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Change VNF flavour\" operation. * NOTE 1:\tThe indication of externally-managed internal VLs is needed in case networks have been\n pre-configured for use with certain VNFs, for instance to ensure that these networks have certain\n properties such as security or acceleration features, or to address particular network topologies.\n The present document assumes that externally-managed internal VLs are managed by the NFVO and\n created towards the VIM.\n NOTE 2: The target size for VNF instantiation may be specified in either instantiationLevelId or \n targetScaleLevelInfo, but not both. If none of the two attributes (instantiationLevelId \n or targetScaleLevelInfo) are present, the default instantiation level as declared in the \n VNFD shall be used.\n NOTE 3: If targetScaleLevelInfo is specified, information provided in targetScaleLevelInfo shall \n be used for instantiating scalable constituents of the VNF (e.g, VDUs/VLs). For scaling \n aspects not specified in targetScaleLevelInfo or for the VNF constituents (e.g., VDUs/VLs) \n that are not scalable, the default instantiation level as declared in the VNFD shall be used \n for instantiation.\n","type":"object","required":["newFlavourId"],"properties":{"newFlavourId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"instantiationLevelId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"targetScaleLevelInfo":{"description":"This attribute is applicable if VNF supports target scale level instantiation. For each scaling aspect of the current deployment flavour, the attribute specifies the scale level of VNF constituents (e.g., VDU level) to be instantiated. See notes 2 and 3.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleLevel":{"description":"Indicates the scale level. The minimum value shall be 0 and the maximum value shall be <= maxScaleLevel as described in the VNFD.\n","type":"integer"}}}},"extVirtualLinks":{"description":"Information about external VLs to connect the VNF to, including configuration information for the CPs via which the VNF instance can attach to this VL. Entries in the list of external VLs that are unchanged need not be supplied as part of this request. The following applies to the \"ExtVirtualLinkData\" information provided in this request, together with the related \"ExtVirtualLinkInfo\" information known to the VNFM represented in the \"VnfInstance\" structure (see clause 5.5.2.2): Even if the VNF is not in fully scaled-out state after changing the flavour, the API consumer shall provide enough CP configuration records to allow connecting the VNF instance, fully scaled out in all scaling aspects, to the external VLs.\n","type":"array","items":{"description":"This type represents an external VL. * NOTE 1: The information about the VIM connection referenced by the VIM connection id is known to the VNFM. \n Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2:\t A link port is not needed for an external CP instance that exposes a CP in the following cases:\n 1) For a virtual IP CP directly exposed as an external CP:\n 1.1) No dedicated IP address is allocated as virtual IP address, as indicated in the VNFD.\n 1.2) A dedicated IP address is allocated as virtual IP address, but the NFVO indicates that no port is\n needed (createExtLinkPort in VnfExtCpconfig set to false).\n 2) For a virtual IP CP exposed as an external CP via a floating IP address:\n 2.1) No dedicated IP address is allocated as virtual IP address, as indicated in the VNFD, and the VNFC\n CP associated to the virtual IP CP is also exposed via a floating IP address.\n 3) For a VIRTUAL CP exposed as an external CP.\n 4) For a VNFC CP exposed as an external CP in a secondary container cluster external network.\n\n* NOTE 3: An example of the network attachment definition resource when the container infrastructure service\n management is a Kubernetes® instance is a network attachment definition (NAD).\n\n* NOTE 4: Either \"extCps\" or “extCpsDeletion\" shall be present, but not both.\n","type":"object","required":["id","resourceId"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"extCps":{"description":"External CPs of the VNF to be connected to this external VL. Entries in the list of external CP data that are unchanged need not be supplied if the ExtVirtualLinkData structure is part of a request or response that modifies the external connectivity.See note 4.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD. The key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO. The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5 and 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored.\n\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for \n Kubernetes® that supports configuration of address pools for load balancer services.\n\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"string"},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"string"}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}}}}},"extLinkPorts":{"description":"Externally provided link ports to be used to connect external connection points to this external VL. If this attribute is not present, the VNFM shall create the link ports on the external VL except in the cases defined below. See note 2.\n","type":"array","items":{"description":"This type represents an externally provided link port to be used to connect an external connection point to an external VL. * NOTE:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"extNetAttDefResourceData":{"description":"Externally provided network attachment definition resource(s) that provide the specification of the interface to attach external CPs to this external VL. See note 3. It is only applicable if the external VL is realized by a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"This type represents a network attachment definition resource that provides the specification of the interface to be used to connect one or multiple connection points to a secondary container cluster network realizing a VL.\n","type":"object","required":["netAttDefResourceId","resourceHandle"],"properties":{"netAttDefResourceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"extCpsDeletion":{"description":"External CPs of the VNF to be disconnected from this external VL and to be deleted. See note 4.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD. The key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO. The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5 and 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored.\n\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for \n Kubernetes® that supports configuration of address pools for load balancer services.\n\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"string"},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"string"}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}}}}}}}},"extManagedVirtualLinks":{"description":"Information about external VLs to connect the VNF to. See note 1.\n","type":"array","items":{"description":"This type represents an externally-managed internal VL. * NOTE:\tThe information about the VIM connection referenced by the VIM connection id is known to the VNFM.\n Moreover, the identifier of the VIM connection provides scope to the resourceId.\n","type":"object","required":["id","virtualLinkDescId","resourceId"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"selectedDeployableModule":{"description":"Identifier of a selected deployable module. Only VNFCs based on VDUs that belong to deployable modules listed in this attribute are requested to be instantiated.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceCapacityDefinition":{"description":"Indicates values for resource capacity related attributes pertaining to a descriptor. Values can only be provided for resource capacity related attributes that have been defined in the VNFD as being configurable. Furthermore, provided values shall be within the allowed values indicated in the VNFD.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes. The tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request. At most one tag can be included when the data type is used in a VNF LCM operation request. When the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced. VALUES •\tCOMPUTE •\tSTORAGE •\tOSCONTAINER","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute ‘type’ indicates OSCONTAINER and absent otherwise.","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource.See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resources_property in the VNFD that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["resourceTemplateId"]},{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD for this virtual compute descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"certificateConfigurationData":{"description":"This type provides input information related to certificate management.\n","type":"object","required":["securityPolicy"],"properties":{"overridingCertificateProfile":{"description":"Overriding certificate profile. This overrides the certificateBaseProfile provided in the VNFD, and the CA and CMF can additionally override aspects of this certificateBaseProfile at later point in the VNF lifecycle if necessary to meet operator security policy.\n","type":"array","items":{"description":"This type provides input information to override certificate base profile for certificate management\nNOTE : At least one overriding attributes shall be present, otherwise shall be absent.\n","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"type":"string","description":"Issuer of certificates. See note."},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to subject of certificate.\n* NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of certification target subject FQDN. See note.","type":"string"},"organization":{"description":"Information of certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of certification target subject Country. See note.","type":"string"},"state":{"description":"Information of certification target subject State. See note.","type":"string"},"locality":{"description":"Information of certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"type":"string","description":"Basic constraints of certificates. See note.\n"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [7],clause 7.1.19.4). See note","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}}},"securityPolicy":{"description":"Security policy to be satisfied for certificate.\n","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"integer"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"integer"}}}},"cmfData":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["endPoint","supportedProtocol"],"properties":{"endPoint":{"description":"End point of CMF instance.","type":"object","required":["ipAddress","link"],"properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocol":{"description":"Supported protocols by CMF instance.","type":"array","items":{"type":"string","enum":["CMP","CMPv2","EST","SCEP"]}}}}}}}}}},"required":true},"VnfInstanceTerminationRequest":{"description":"Parameters for the VNF termination.","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Terminate VNF\" operation. * NOTE:\tIn case of forceful termination, the VNF instance is terminated immediately.\n If the VNF is still in service, this can adversely impact the network service,\n and therefore, the EM needs to determine if forceful termination is applicable\n in the particular situation.\n","type":"object","required":["terminationType"],"properties":{"terminationType":{"description":"Indicates the type of termination is requested. See note. Permitted values: * FORCEFUL: The VNFM will shut down the VNF and release the resources immediately after accepting the request. * GRACEFUL: The VNFM will first arrange to take the VNF out of service after accepting the request. Once the operation of taking the VNF out of service finishes (irrespective of whether it has succeeded or failed) or\n once the timer value specified in the \"gracefulTerminationTimeout\" attribute expires, the VNFM will shut down\n the VNF and release the resources.\n","type":"string","enum":["FORCEFUL","GRACEFUL"]},"gracefulTerminationTimeout":{"description":"This attribute is only applicable in case of graceful termination. It defines the time to wait for the VNF to be taken out of service before shutting down the VNF and releasing the resources. The unit is seconds. If not given and the \"terminationType\" attribute is set to \"GRACEFUL\", it is expected that the VNFM waits for the successful taking out of service of the VNF, no matter how long it takes, before shutting down the VNF and releasing the resources.\n","type":"integer"},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"required":true},"VnfInstanceHealRequest":{"description":"Parameters for the Heal VNF operation.","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Heal VNF\" operation.\n","type":"object","properties":{"vnfcInstanceId":{"description":"List of identifiers of VNFC instances for which a healing action is requested. Each identifier references the \"id\" attribute in a \"VnfcInfo\" structure. Cardinality can be \"0\" to denote that the request applies to the whole VNF and not a specific VNFC instance.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cause":{"description":"Indicates the reason why a healing procedure is required.\n","type":"string"},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"healScript":{"description":"Provides link to a script that should be executed as part of the healing action or a set of rules for healing procedure.\n","type":"string"},"healingResource":{"description":"Indicates the kinds of the virtual resource to be healed. Permitted values:\n •\tVL\n •\tLINKPORT\n •\tSTORAGE\n •\tVIRTUALCP\n •\tCOMPUTE\n •\tOSCONTAINER\n\nDefault value is COMPUTE when the VDUs of the VNF are realized by a set of virtual machines and OSCONTAINER when the VDUs of the VNF are realized by a set of OS containers.\n","type":"array","items":{"type":"string","enum":["VL","LINKPORT","STORAGE","VIRTUALCP","COMPUTE","OSCONTAINER"]}}}}}},"required":true},"VnfInstanceOperateRequest":{"description":"Parameters for the Operate VNF operation.","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Operate VNF\" operation. * NOTE:\tThe \"stopType\" and \"gracefulStopTimeout\" attributes shall be absent, when the \"changeStateTo\"\n attribute is equal to \"STARTED\". The \"gracefulStopTimeout\" attribute shall be present, when the\n \"changeStateTo\" is equal to \"STOPPED\" and the \"stopType\" attribute is equal to \"GRACEFUL\".\n The \"gracefulStopTimeout\" attribute shall be absent, when the \"changeStateTo\" attribute is equal to\n \"STOPPED\" and the \"stopType\" attribute is equal to \"FORCEFUL\". The request shall be treated as if\n the \"stopType\" attribute has been set to \"FORCEFUL\", when the \"changeStateTo\" attribute is equal\n to \"STOPPED\" and the \"stopType\" attribute is absent.\n","type":"object","required":["changeStateTo"],"properties":{"vnfcInstanceId":{"description":"List of identifiers of VNFC instances. Each identifier references the \"id\" attribute in a \"VnfcInfo\" structure. Cardinality can be \"0\" to denote that the request applies to the whole VNF and not a specific VNFC instance.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"changeStateTo":{"description":"STARTED: The VNF instance is up and running. STOPPED: The VNF instance has been shut down.\n","type":"string","enum":["STARTED","STOPPED"]},"stopType":{"description":"It signals whether forceful or graceful stop is requested. See note\n","type":"string","enum":["FORCEFUL","GRACEFUL"]},"gracefulStopTimeout":{"description":"The time interval (in seconds) to wait for the VNF to be taken out of service during graceful stop, before stopping the VNF. See note.\n","type":"integer"},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"required":true},"VnfInstanceChangeExtConnRequest":{"description":"Parameters for the Change external VNF connectivity operation.\n","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Change external VNF connectivity\" operation to modify the external connectivity of a VNF instance. The following behaviour applies for the changes that can be performed with this operation: To change the connection of external CP instances based on certain external CPDs from a \"source\" external \n VL to a different \"target\" external VL, the identifier of the \"target\" external VL shall be sent in the \n \"extVirtualLinkId\" attribute of the \"extVirtualLinks\" parameter, and the \"extCps\" attributes of that parameter \n shall refer via the \"cpdId\" attribute to the external CPDs of the corresponding external connection point \n instances that are to be reconnected to the target external VL. \n* NOTE 1: For CP instances that are not part of a trunk this means that all CP instances based on a given external CPD will be reconnected. See clause B.3.3 for an illustration. Likewise, for CP instances that are part of a \n trunk and have the same segmentationId, all CP instances (subports) based on a given external CPD will \n be connected, disconnected or reconnected.\n \n To change the connectivity parameters of the external CPs connected to a particular external VL, including \n changing addresses, the identifier of that external VL shall be sent in the \"extVirtualLinkId\" attribute of the \n \"extVirtualLinks\" parameter, and the \"extCps\" attribute of that parameter shall contain at least those entries \n with modified parameters.\n\n To create a new external CP instance, this shall be based on a certain external CPD that is referenced by at \n least a VDU from which the VNF instance has at least one VNFC instantiated. The newly external CP instance \n connects to the same external VL as other CP instances created based on the same CPD. For creating a new \n external CP instance:\n The \"extVirtualLinkId\" attribute of the \"extVirtualLinks\" parameter indicates the identifier of the \n external VL instance to which the new external CP instance is requested to be connected (refer to \n above behavior).\n \n The \"extCps\" attribute shall refer via the \"cpdId\" attribute to the external CPDs from which a new \n instance is to be created.\n\n* NOTE 2: For the capability to connect to different external VLs, refer to the use of subports. To delete an existing external CP instance:\n The \"extVirtualLinkId\" attribute of the \"extVirtualLinks\" parameter indicates the identifier of the \n external VL instance from which the existing external CP instance is requested to be disconnected.\n \n The \"extCpsDeletion\" attribute shall refer via the \"cpdId\" attribute to the external CPD from which a \n corresponding CP instance will be deleted.\n\n The \" parentCpConfigId\" of the contained \"cpConfig\" in the \"extCps\" shall refer to the particular \n external CP instance to be deleted.\n\n* NOTE 3: If external CPs are requested to be created and connected, and disconnected and deleted in a same operation request, the consumer can provide respective \"extVirtualLinks\", e.g., one for the external CPs \n to be created and connected, and one for the external CPs to disconnect and delete.\n","type":"object","required":["extVirtualLinks"],"properties":{"extVirtualLinks":{"description":"Information about external VLs to change (e.g. connect the VNF to) including configuration information for the CPs via which the VNF instance can attach to this VL. Entries in the list of external VLs that are unchanged need not be supplied as part of this request. The following applies to the \"ExtVirtualLinkData\" information provided in this request, together with the related \"ExtVirtualLinkInfo\" information known to the VNFM represented in the \"VnfInstance\" structure (see clause 5.5.2.2): Even if the VNF is not in fully scaled-out state, the API consumer shall provide enough CP configuration records to allow connecting the VNF instance, fully scaled out in all scaling aspects, to the external VLs.\n","type":"array","items":{"description":"This type represents an external VL. * NOTE 1: The information about the VIM connection referenced by the VIM connection id is known to the VNFM. \n Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2:\t A link port is not needed for an external CP instance that exposes a CP in the following cases:\n 1) For a virtual IP CP directly exposed as an external CP:\n 1.1) No dedicated IP address is allocated as virtual IP address, as indicated in the VNFD.\n 1.2) A dedicated IP address is allocated as virtual IP address, but the NFVO indicates that no port is\n needed (createExtLinkPort in VnfExtCpconfig set to false).\n 2) For a virtual IP CP exposed as an external CP via a floating IP address:\n 2.1) No dedicated IP address is allocated as virtual IP address, as indicated in the VNFD, and the VNFC\n CP associated to the virtual IP CP is also exposed via a floating IP address.\n 3) For a VIRTUAL CP exposed as an external CP.\n 4) For a VNFC CP exposed as an external CP in a secondary container cluster external network.\n\n* NOTE 3: An example of the network attachment definition resource when the container infrastructure service\n management is a Kubernetes® instance is a network attachment definition (NAD).\n\n* NOTE 4: Either \"extCps\" or “extCpsDeletion\" shall be present, but not both.\n","type":"object","required":["id","resourceId"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"extCps":{"description":"External CPs of the VNF to be connected to this external VL. Entries in the list of external CP data that are unchanged need not be supplied if the ExtVirtualLinkData structure is part of a request or response that modifies the external connectivity.See note 4.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD. The key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO. The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5 and 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored.\n\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for \n Kubernetes® that supports configuration of address pools for load balancer services.\n\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"string"},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"string"}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}}}}},"extLinkPorts":{"description":"Externally provided link ports to be used to connect external connection points to this external VL. If this attribute is not present, the VNFM shall create the link ports on the external VL except in the cases defined below. See note 2.\n","type":"array","items":{"description":"This type represents an externally provided link port to be used to connect an external connection point to an external VL. * NOTE:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"extNetAttDefResourceData":{"description":"Externally provided network attachment definition resource(s) that provide the specification of the interface to attach external CPs to this external VL. See note 3. It is only applicable if the external VL is realized by a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"This type represents a network attachment definition resource that provides the specification of the interface to be used to connect one or multiple connection points to a secondary container cluster network realizing a VL.\n","type":"object","required":["netAttDefResourceId","resourceHandle"],"properties":{"netAttDefResourceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"extCpsDeletion":{"description":"External CPs of the VNF to be disconnected from this external VL and to be deleted. See note 4.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD. The key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO. The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5 and 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored.\n\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for \n Kubernetes® that supports configuration of address pools for load balancer services.\n\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"string"},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"string"}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}}}}}}}},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateConfigurationData":{"description":"This type provides input information related to certificate management.\n","type":"object","required":["securityPolicy"],"properties":{"overridingCertificateProfile":{"description":"Overriding certificate profile. This overrides the certificateBaseProfile provided in the VNFD, and the CA and CMF can additionally override aspects of this certificateBaseProfile at later point in the VNF lifecycle if necessary to meet operator security policy.\n","type":"array","items":{"description":"This type provides input information to override certificate base profile for certificate management\nNOTE : At least one overriding attributes shall be present, otherwise shall be absent.\n","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"type":"string","description":"Issuer of certificates. See note."},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to subject of certificate.\n* NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of certification target subject FQDN. See note.","type":"string"},"organization":{"description":"Information of certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of certification target subject Country. See note.","type":"string"},"state":{"description":"Information of certification target subject State. See note.","type":"string"},"locality":{"description":"Information of certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"type":"string","description":"Basic constraints of certificates. See note.\n"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [7],clause 7.1.19.4). See note","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}}},"securityPolicy":{"description":"Security policy to be satisfied for certificate.\n","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"integer"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"integer"}}}},"cmfData":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["endPoint","supportedProtocol"],"properties":{"endPoint":{"description":"End point of CMF instance.","type":"object","required":["ipAddress","link"],"properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocol":{"description":"Supported protocols by CMF instance.","type":"array","items":{"type":"string","enum":["CMP","CMPv2","EST","SCEP"]}}}}}}}}}},"required":true},"VnfInstanceChangeVnfPkgRequest":{"description":"Parameters for the Change current VNF package operation.\n","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Change current VNF package\" operation to replace the VNF package on which a VNF instance is based. * NOTE 1:\tThe indication of externally-managed internal VLs is needed in case networks have been\n pre-configured for use with certain VNFs, for instance to ensure that these networks have certain\n properties such as security or acceleration features, or to address particular network topologies.\n The present document assumes that externally-managed internal VLs are managed by the NFVO and created\n towards the VIM.\n* NOTE 2: Component mappings are defined in the VNFD in the source or destination package for the relevant change\n path. See clause 7.1.15.2 in ETSI GS NFV-IFA 011 [7].\n* NOTE 3: In the current version of the present document, only Rolling upgrade and Blue-green upgrade types \n are supported. The definition of additional upgrade types is left for future specification.\n","type":"object","required":["vnfdId"],"properties":{"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"extVirtualLinks":{"description":"Information about external VLs to connect the VNF to, including configuration information for the CPs via which the VNF instance can attach to this VL. Entries in the list that are unchanged need not be supplied as part of this request. The following applies to the \"ExtVirtualLinkData\" information provided in this request, together with the related \"ExtVirtualLinkInfo\" information known to the VNFM represented in the \"VnfInstance\" structure (see clause 5.5.2.2): Even if the VNF is not in fully scaled-out state after the change of the VNF package, the API consumer shall provide enough CP configuration records to allow connecting the VNF instance, fully scaled out in all scaling aspects, to the external VLs.\n","type":"array","items":{"description":"This type represents an external VL. * NOTE 1: The information about the VIM connection referenced by the VIM connection id is known to the VNFM. \n Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2:\t A link port is not needed for an external CP instance that exposes a CP in the following cases:\n 1) For a virtual IP CP directly exposed as an external CP:\n 1.1) No dedicated IP address is allocated as virtual IP address, as indicated in the VNFD.\n 1.2) A dedicated IP address is allocated as virtual IP address, but the NFVO indicates that no port is\n needed (createExtLinkPort in VnfExtCpconfig set to false).\n 2) For a virtual IP CP exposed as an external CP via a floating IP address:\n 2.1) No dedicated IP address is allocated as virtual IP address, as indicated in the VNFD, and the VNFC\n CP associated to the virtual IP CP is also exposed via a floating IP address.\n 3) For a VIRTUAL CP exposed as an external CP.\n 4) For a VNFC CP exposed as an external CP in a secondary container cluster external network.\n\n* NOTE 3: An example of the network attachment definition resource when the container infrastructure service\n management is a Kubernetes® instance is a network attachment definition (NAD).\n\n* NOTE 4: Either \"extCps\" or “extCpsDeletion\" shall be present, but not both.\n","type":"object","required":["id","resourceId"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"extCps":{"description":"External CPs of the VNF to be connected to this external VL. Entries in the list of external CP data that are unchanged need not be supplied if the ExtVirtualLinkData structure is part of a request or response that modifies the external connectivity.See note 4.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD. The key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO. The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5 and 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored.\n\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for \n Kubernetes® that supports configuration of address pools for load balancer services.\n\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"string"},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"string"}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}}}}},"extLinkPorts":{"description":"Externally provided link ports to be used to connect external connection points to this external VL. If this attribute is not present, the VNFM shall create the link ports on the external VL except in the cases defined below. See note 2.\n","type":"array","items":{"description":"This type represents an externally provided link port to be used to connect an external connection point to an external VL. * NOTE:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"extNetAttDefResourceData":{"description":"Externally provided network attachment definition resource(s) that provide the specification of the interface to attach external CPs to this external VL. See note 3. It is only applicable if the external VL is realized by a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"This type represents a network attachment definition resource that provides the specification of the interface to be used to connect one or multiple connection points to a secondary container cluster network realizing a VL.\n","type":"object","required":["netAttDefResourceId","resourceHandle"],"properties":{"netAttDefResourceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"extCpsDeletion":{"description":"External CPs of the VNF to be disconnected from this external VL and to be deleted. See note 4.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD. The key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO. The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5 and 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored.\n\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for \n Kubernetes® that supports configuration of address pools for load balancer services.\n\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"string"},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"string"}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}}}}}}}},"extManagedVirtualLinks":{"description":"Information about internal VLs that are managed by other entities than the VNFM. See note.\n","type":"array","items":{"description":"This type represents an externally-managed internal VL. * NOTE:\tThe information about the VIM connection referenced by the VIM connection id is known to the VNFM.\n Moreover, the identifier of the VIM connection provides scope to the resourceId.\n","type":"object","required":["id","virtualLinkDescId","resourceId"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"selectedDeployableModule":{"description":"Identifier of a selected deployable module. If this attribute is present only VNFCs based on VDUs that belong to deployable modules listed in this attribute are requested to be instantiated or preserved if they were already instantiated. If this attribute is not present the deployable modules that were selected before the operation, and that still are defined in the VNFD in the destination package, or the corresponding ones according to the component mappings, remain valid. See note 2.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceCapacityDefinition":{"description":"Indicates values for resource capacity related attributes pertaining to a descriptor. Values can only be provided for resource capacity related attributes that have been defined in the VNFD as being configurable. Furthermore, provided values shall be within the allowed values indicated in the VNFD.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes. The tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request. At most one tag can be included when the data type is used in a VNF LCM operation request. When the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced. VALUES •\tCOMPUTE •\tSTORAGE •\tOSCONTAINER","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute ‘type’ indicates OSCONTAINER and absent otherwise.","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource.See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resources_property in the VNFD that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["resourceTemplateId"]},{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD for this virtual compute descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"certificateConfigurationData":{"description":"This type provides input information related to certificate management.\n","type":"object","required":["securityPolicy"],"properties":{"overridingCertificateProfile":{"description":"Overriding certificate profile. This overrides the certificateBaseProfile provided in the VNFD, and the CA and CMF can additionally override aspects of this certificateBaseProfile at later point in the VNF lifecycle if necessary to meet operator security policy.\n","type":"array","items":{"description":"This type provides input information to override certificate base profile for certificate management\nNOTE : At least one overriding attributes shall be present, otherwise shall be absent.\n","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"type":"string","description":"Issuer of certificates. See note."},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to subject of certificate.\n* NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of certification target subject FQDN. See note.","type":"string"},"organization":{"description":"Information of certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of certification target subject Country. See note.","type":"string"},"state":{"description":"Information of certification target subject State. See note.","type":"string"},"locality":{"description":"Information of certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"type":"string","description":"Basic constraints of certificates. See note.\n"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [7],clause 7.1.19.4). See note","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}}},"securityPolicy":{"description":"Security policy to be satisfied for certificate.\n","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"integer"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"integer"}}}},"cmfData":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["endPoint","supportedProtocol"],"properties":{"endPoint":{"description":"End point of CMF instance.","type":"object","required":["ipAddress","link"],"properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocol":{"description":"Supported protocols by CMF instance.","type":"array","items":{"type":"string","enum":["CMP","CMPv2","EST","SCEP"]}}}}}},"upgradeType":{"description":"Indicates upgrade type when change the current VNF Package on which a VNF instance is based. Permitted values: •\tROLLING_UPGRADE •\tBLUE_GREEN See note 3.\n","type":"string","enum":["ROLLING_UPGRADE","BLUE_GREEN"]}}}}},"required":true},"VnfLcmSubscriptionRequest":{"description":"Details of the subscription to be created.\n","content":{"application/json":{"schema":{"description":"This type represents a subscription request related to notifications about VNF lifecycle changes.\n","type":"object","required":["callbackUri"],"properties":{"filter":{"description":"This type represents a subscription filter related to notifications about VNF lifecycle changes.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of \n the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdIds"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tVnfLcmOperationOccurrenceNotification -\tVnfIdentifierCreationNotification -\tVnfIdentifierDeletionNotification See note.\n","type":"array","items":{"type":"string","enum":["VnfLcmOperationOccurrenceNotification","VnfIdentifierCreationNotification","VnfIdentifierDeletionNotification"]}},"operationTypes":{"description":"Match particular VNF lifecycle operation types for the notification of type VnfLcmOperationOccurrenceNotification. May be present if the \"notificationTypes\" attribute contains the value \"VnfLcmOperationOccurrenceNotification\", and shall be absent otherwise.\n","type":"array","items":{"description":"The enumeration LcmOpType defines the permitted values to represent VNF lifecycle operation types in VNF lifecycle management operation occurrence resources and VNF lifecycle management operation occurrence notifications.\nValue | Description ------|------------ INSTANTIATE | Represents the \"Instantiate VNF\" LCM operation. SCALE | Represents the \"Scale VNF\" LCM operation. SCALE_TO_LEVEL | Represents the \"Scale VNF to Level\" LCM operation. CHANGE_FLAVOUR | Represents the \"Change VNF Flavour\" LCM operation. TERMINATE | Represents the \"Terminate VNF\" LCM operation. HEAL | Represents the \"Heal VNF\" LCM operation. OPERATE | Represents the \"Operate VNF\" LCM operation. CHANGE_EXT_CONN | Represents the \"Change external VNF connectivity\" LCM operation. MODIFY_INFO | Represents the \"Modify VNF Information\" LCM operation. CREATE_SNAPSHOT | Represents the \"Create VNF Snapshot\" LCM operation. REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot\" LCM operation. CHANGE_VNFPKG | Represents the \"Change current VNF package\" LCM operation. SELECT_DEPL_MODS | Represents the \"Select VNF deployable modules\" LCM operation\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","MODIFY_INFO","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","CHANGE_VNFPKG","SELECT_DEPL_MODS"]}},"operationStates":{"description":"Match particular LCM operation state values as reported in notifications of type VnfLcmOperationOccurrenceNotification. May be present if the \"notificationTypes\" attribute contains the value \"VnfLcmOperationOccurrenceNotification\", and shall be absent otherwise.\n","type":"array","items":{"description":"STARTING: The LCM operation is starting. PROCESSING: The LCM operation is currently in execution. COMPLETED: The LCM operation has been completed successfully. FAILED_TEMP: The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED: The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK: The LCM operation is currently being rolled back. ROLLED_BACK: The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible.\n","type":"string","enum":["STARTING","PROCESSING","COMPLETED","FAILED_TEMP","FAILED","ROLLING_BACK","ROLLED_BACK"]}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE 1 : The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between\n subscriptions. The value of clientPassword should be generated by a random process.\n* NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT which uses mutual authentication based on X.509 certificates, this mode which uses client password to authenticate may be used in the access token request\n toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations\n (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details.\n* NOTE 3: The following values that were included up to version 3.4.1 of the present document have been removed: \"BASIC\" (to signal the use of the basic HTTP authentication) has been removed because it is insecure.\n \"TLS_CERT\" to signal an alternative non-token based authorization method using TLS certificates has been\n removed because the method is no longer supported.\n* NOTE 4: The client certificate is established by means outside the scope of the present document.\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values (see note 3): * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use\n an OAuth 2.0 token, obtained using the client\n credentials grant type after authenticating\n using client identifier and client password\n towards the token endpoint.\n* OAUTH2_CLIENT_CERT: In every HTTP request to the notification endpoint, use an\n OAuth 2.0 token, obtained using the client\n credentials grant type after mutually\n authenticating using client identifier and X.509\n certificates towards the token endpoint.\n","type":"array","items":{"type":"string","enum":["OAUTH2_CLIENT_CREDENTIALS","OAUTH2_CLIENT_CERT"]}},"paramsOauth2ClientCert":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CERT.\nShall be present if authType is \"OAUTH2_CLIENT_CERT\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\n","type":"object","required":["clientId","certificateRef","tokenEndpoint"],"properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint.\n","type":"string"},"certificateRef":{"description":"Fingerprint of the client certificate. The hash function shall use SHA256 or higher. See note 4.\n","type":"string","required":["type","value"],"properties":{"type":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"value":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS.\nShall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\nSee note 2.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"clientPassword":{"description":"Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"verbosity":{"description":"The enumeration LcmOpOccNotificationVerbosityType provides values to control the verbosity of LCM operation occurrence notifications. * FULL: This signals a full notification which contains all change details. * SHORT: This signals a short notification which omits large-volume change details to reduce the size of data to be sent via the notification mechanism.\n","type":"string","enum":["FULL","SHORT"]}}}}},"required":true},"VnfInstanceCreateSnapshotRequest":{"description":"Parameters for the “Create VNF/VNFC Snapshot” operation.\n","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Create VNF Snapshot\" operation.\n","type":"object","required":["vnfSnapshotResId"],"properties":{"vnfSnapshotInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"required":true},"VnfInstanceRevertToSnapshotRequest":{"description":"Parameters for the Revert-to VNF/VNFC snapshot operation.\n","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Revert-to VNF Snapshot\" operation.\n","type":"object","properties":{"vnfSnapshotInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcSnapshotInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"required":true},"VnfSnapshotsRequest":{"description":"The VNF snapshot resource creation parameters.\n","content":{"application/json":{"schema":{"description":"This type represents request parameters for the creation of an \"Individual VNF snapshot\" resource which can be\npopulated with content obtained by invoking the \"Create VNF snapshot\" LCM operation or extracted from a VNF\nsnapshot package.\n* NOTE: The present attribute shall be provided if the \"Individual VNF snapshot\" resource is requested to be created and be filled from a VNF snapshot package extraction.\n","type":"object","properties":{"vnfSnapshotPkgId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"required":true}},"responses":{"VnfInstances.Get.200":{"description":"200 OK\nShall be returned when information about zero or more VNF instances has been queried successfully.\nThe response body shall contain in an array the representations of zero or more VNF instances,\nas defined in clause 5.5.2.2.\nIf the \"filter\" URI parameter or one of the \"all_fields\", \"fields\" (if supported), \"exclude_fields\"\n(if supported) or \"exclude_default\" URI parameters was supplied in the request, the data in the response\nbody shall have been transformed according to the rules specified in clauses 5.2.2 and 5.3.2 of\nETSI GS NFV-SOL 013, respectively.\nIf the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013\nfor this resource, inclusion of the Link HTTP header in this response shall follow the provisions\nin clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a VNF instance. * NOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist\n between the previous and the newly referred VNF package, i.e. when the new VNFD is\n changed with respect to the previous VNFD in other aspects than merely referencing\n to other VNF software images. In order to avoid misalignment of the VnfInstance with\n the current VNF's on-boarded VNF package, the values of attributes in the VnfInstance\n that have corresponding attributes in the VNFD shall be kept in sync with the values in the VNFD.\n* NOTE 2:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 3:\tThese attributes are sometimes also referred to as configuration parameters\n applicable to a VNF. Some of these are set prior to instantiation and cannot be modified\n if the VNF is instantiated, some are set prior to instantiation (are part of initial configuration)\n and can be modified later, and others can be set only after instantiation.\n The applicability of certain configuration may depend on the VNF and the required operation of\n the VNF at a certain point in time.\n* NOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child\n attributes of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared\n in the VNFD with a defined initial value. The defined initial values can be declared in the VNFD,\n and/or, in case of \"metadata\", obtained from the \"CreateVnfRequest\" structure. Child attributes of\n \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that have no defined initial value shall\n not be created, in order to be consistent with the semantics of the JSON Merge Patch method\n (see IETF RFC 7396) that interprets null values as deletion request.\n* NOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case\n of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding\n to the same VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc\n and externally-managed multi-site VL instance (refer to clause 5.5.3.5).\n* NOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity,\n they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n* NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual extCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the VNF \n LCM operation explicitly indicates the scale level for the aspect.\n* NOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n","type":"object","required":["id","vnfdId","vnfProvider","vnfProductName","vnfSoftwareVersion","vnfdVersion","instantiationState","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceName":{"description":"Name of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfInstanceDescription":{"description":"Human-readable description of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"Provider of the VNF and the VNFD. The value is copied from the VNFD.\n","type":"string"},"vnfProductName":{"description":"Name to identify the VNF Product. The value is copied from the VNFD.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateInfo":{"description":"This type provides input information related to certificate and certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateConfigurationInfo":{"description":"This type provides input information related to certificate management.\n","type":"object","required":["securityPolicy"],"properties":{"certificateBaseProfile":{"description":"This type provides input information to override certificate base profile for certificate management\nNOTE : At least one overriding attributes shall be present, otherwise shall be absent.\n","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"type":"string","description":"Issuer of certificates. See note."},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to subject of certificate.\n* NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of certification target subject FQDN. See note.","type":"string"},"organization":{"description":"Information of certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of certification target subject Country. See note.","type":"string"},"state":{"description":"Information of certification target subject State. See note.","type":"string"},"locality":{"description":"Information of certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"type":"string","description":"Basic constraints of certificates. See note.\n"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [7],clause 7.1.19.4). See note","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}},"securityPolicy":{"description":"Information for security policy to be satisfied for certificate.\n","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"integer"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"integer"}}}},"delegationSupportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"cmfInfo":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["id","endPoint","supportedProtocol"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"endPoint":{"description":"End point of CMF instance.","type":"object","required":["ipAddress","link"],"properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocols":{"description":"Supported protocol by CMF instance.","type":"array","items":{"type":"string","enum":["CMP","CMPv2","EST","SCEP"]}},"certificateChain":{"description":"Certificate chain that this CMF provides.","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"certificateContents":{"description":"Information for contents of issued certificates. The information contained in this attribute may be updated over time during the VNF LCM, e.g. certificate(s) renewal.\n","type":"array","items":{"description":"This type provides input information related to certificate content.\n","type":"object","required":["id","certificateDescId","certificateType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certficateDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"certificateType":{"description":"Type of this certificate.","type":"string","enum":["VNFCI_CERT","VNFOAM_CERT"]},"supportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"version":{"description":"A version.\n","type":"string"},"serialNumber":{"description":"Serial number of this certificate.","type":"integer"},"signatureAlgorithm":{"description":"Algorithm of this certificate's signature.","type":"string"},"issuer":{"description":"Issuer of this certificate.","type":"string"},"notBefore":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"notAfter":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"subject":{"description":"Subject of this certificate.","type":"string"},"publicKeyAlgorithm":{"description":"Algorithm of this certificate's public key.","type":"string"},"publicKey":{"description":"Public key of this certificate.","type":"string"},"certificateExtensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"instantiationState":{"description":"The instantiation state of the VNF.\n","type":"string","enum":["NOT_INSTANTIATED","INSTANTIATED"]},"instantiatedVnfInfo":{"description":"Information specific to an instantiated VNF instance. This attribute shall be present if the instantiateState attribute value is INSTANTIATED.\n","type":"object","required":["flavourId","vnfState","extCpInfo"],"properties":{"flavourId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfState":{"description":"STARTED: The VNF instance is up and running. STOPPED: The VNF instance has been shut down.\n","type":"string","enum":["STARTED","STOPPED"]},"vnfPowerState":{"description":"This type represents information about the power state of a VNF instance.\n","type":"object","required":["powerProfileId","name"],"properties":{"powerProfileId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Name of the power profile as provided in the VNFD.\n","type":"string"},"powerConsumptionInfo":{"description":"This type represents information about estimated power consumption of the resources associated with the power profile, as provided in the VNFD.\n","type":"object","required":["minPowerConsumption","maxPowerConsumption","averagePowerConsumption"],"properties":{"minPowerConsumption":{"description":"Minimum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"maxPowerConsumption":{"description":"Maximum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"averagePowerConsumption":{"description":"Average power consumption of this power profile. Unit is KW/h.\n","type":"integer"}}}}},"scaleStatus":{"description":"Scale status of the VNF, one entry per aspect. Represents for every scaling aspect how \"big\" the VNF has been scaled w.r.t. that aspect. This attribute shall be present if the VNF supports scaling. See clause B.2 for an explanation of VNF scaling. For an aspect that has not been deployed because the related deployableModule has not been selected, it indicates the scale level that has been requested in the instantiation or in a scaling operation, or, if none has been requested in any of them, the scale level applicable to the aspect based on the default instantiation level. See note 8.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleLevel":{"description":"Indicates the scale level. The minimum value shall be 0 and the maximum value shall be <= maxScaleLevel as described in the VNFD.\n","type":"integer"}}}},"maxScaleLevels":{"description":"Maximum allowed scale levels of the VNF, one entry per aspect. This attribute shall be present if the VNF supports scaling.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleLevel":{"description":"Indicates the scale level. The minimum value shall be 0 and the maximum value shall be <= maxScaleLevel as described in the VNFD.\n","type":"integer"}}}},"selectedDeployableModule":{"description":"References a currently selected deployable module, as defined in the VNFD, that has already completed the instantiation of its VNFCs\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceCapacityDefinition":{"description":"Shows current values of VDU attributes related to resource capacity, if different to the default values from the VNFD, as indicated in the (one or more) request(s) of all completed VNF LCM operation(s) that contain this attribute. If an attribute value has been modified multiple times, only the last value is shown. The values indicated in this attribute are applicable to all VNFC instances based on the VDU to which the resourceCapacityDefinition is related.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes. The tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request. At most one tag can be included when the data type is used in a VNF LCM operation request. When the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced. VALUES •\tCOMPUTE •\tSTORAGE •\tOSCONTAINER","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute ‘type’ indicates OSCONTAINER and absent otherwise.","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource.See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resources_property in the VNFD that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["resourceTemplateId"]},{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD for this virtual compute descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"extCpInfo":{"description":"Information about the external CPs exposed by the VNF instance. When trunking is enabled, the list of entries includes both, external CPs corresponding to parent ports of a trunk, and external CPs associated to sub-ports of a trunk. See note 7.\n","type":"array","minItems":1,"items":{"description":"This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n","type":"object","required":["id","cpdId","cpConfigId","cpProtocolInfo"],"oneOf":[{"required":["associatedVnfcCpId"]},{"required":["associatedVipCpId"]},{"required":["associatedVnfVirtualLinkId"]}],"properties":{"id":{"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"},"cpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extLinkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"associatedVnfcCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVipCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVirtualCpId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"associatedVnfVirtualLinkId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 3 and 4. It shall be present if the external CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"certificateContentId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cpSecurityGroupInfo":{"description":"This type provides the list of active security group rules applied to an external CP instance. The type identifies which \"SecurityGroupRule\" specified in the VNFD are activated and the values of its attributes.\n","type":"object","required":["securityGroupRuleId","etherType","protocol","portRangeMin","portRangeMax"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"description":{"description":"Human readable description of the security group rule.\n","type":"string"},"etherType":{"description":"Indicates the protocol carried over the Ethernet layer. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"protocol":{"description":"Indicates the protocol carried over the IP layer. Permitted values: any protocol defined in the IANA protocol registry (refer to clause 9.10.1.2 ofd ETSI GS NFV-SOL 001 for further information).\n","type":"string"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule.\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule.\n","type":"integer"}}}}}},"vipCpInfo":{"description":"VIP CPs that are part of the VNF instance. Shall be present when that particular VIP CP of the VNFC instance is associated to an external CP of the VNF instance.\nMay be present otherwise.\n","type":"array","items":{"description":"This type provides information related to virtual IP CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["cpInstanceId","cpdId"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for layer 3. There may be one cpProtocolInfo for layer 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"associatedVnfcCpIds":{"description":"Identifiers of the VnfcCps that share the virtual IP address allocated to the VIP CP instance. See note.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualCpInfo":{"description":"Virtual CPs that are part of the VNF instance. Shall be present when a particular virtual CP is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","items":{"description":"This type provides information related to a virtual CP instance of a VNF.\n* NOTE 1: A consumer of the VNF LCM interface can learn the actual VNFC instances implementing the service accessible via the virtual CP instance by querying the \"vnfcResourceInfo\" from the \"InstantiatedVnfInfo\" \n and filtering by corresponding \"vduIds\" values.\n* NOTE 2: The information can be omitted because it is already available as part of the external CP information in the VnfExtCpInfo structure.\n","type":"object","required":["cpInstanceId","cpdId","resourceHandle","vduIds"],"properties":{"cpInstanceId":{"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"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for each layer protocol supported. This attribute may be omitted if the virtual CP is exposed as an external CP. See note 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vduIds":{"description":"Reference to the VDU(s) which implement the service accessible via the virtual CP instance. See note.\n","type":"array","minItems":1,"items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"additionalServiceInfo":{"description":"Additional service identification information of the virtual CP instance.\n","type":"array","items":{"description":"This type provides additional service information of the virtual CP instance used to expose properties of the virtual CP to NFV-MANO.\nNOTE: This attribute shall only be present if additional information is needed to identify the service termination within the VNF, such as for example a URL path information in an HTTP request required \n to allow a single virtual CP IP address to be used for several HTTP based services that use the \n same port number.\n","type":"object","required":["portInfo"],"properties":{"portInfo":{"description":"Service port numbers exposed by the virtual CP instance.\n","minItems":1,"type":"array","items":{"description":"This type describes the service identifying port properties exposed by the virtual CP instance.\n","type":"object","required":["name","port","portConfigurable"],"properties":{"name":{"description":"The name of the port exposed by the virtual CP instance.\n","type":"string"},"protocol":{"description":"The L4 protocol for this port exposed by the virtual CP instance.\nPermitted values: - TCP - UDP - SCTP\n","type":"string","enum":["TCP","UDP","SCTP"]},"port":{"description":"The L4 port number exposed by the virtual CP instance.\n","type":"integer"},"portConfigurable":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"}}}},"serviceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"extVirtualLinkInfo":{"description":"Information about the external VLs the VNF instance is connected to.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD. The key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO. The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5 and 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored.\n\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for \n Kubernetes® that supports configuration of address pools for load balancer services.\n\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"string"},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"string"}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"routingResource":{"description":"Network resources that provide the forwarding/routing capabilities associated to the network resource realizing this VL.\n","type":"array","items":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}}},"extManagedVirtualLinkInfo":{"description":"Information about the externally managed internal VLs of the VNF instance. See note 5 and note 6. It is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed multi-site VL instance (refer to clause 5.5.3.5). Even though externally-managed internal VLs are also used for VNF-internal connectivity, they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n","type":"array","items":{"description":"This type provides information about an externally-managed virtual link. *NOTE: Both vnfLinkPort and vnfNetAttDefResource can be present in an ExtManagedVirtualLinkInfo to indicate that a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPorts":{"description":"Link ports of this VL.See note.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"vnfNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"routingResource":{"description":"Network resources that provide the forwarding/routing capabilities associated to the network resource realizing this VL.\n","type":"array","items":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}}},"monitoringParameters":{"description":"Active monitoring parameters.\n","type":"array","items":{"type":"object","required":["id","performanceMetric"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human readable name of the monitoring parameter, as defined in the VNFD.\n","type":"string"},"performanceMetric":{"description":"Performance metric that is monitored. This attribute shall contain the related \"Measurement Name\" value as defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"}}}},"localizationLanguage":{"description":"Information about localization language of the VNF (includes e.g. strings in the VNFD). The localization languages supported by a VNF can be declared in the VNFD, and localization language selection can take place at instantiation time. The value shall comply with the format defined in IETF RFC 5646.\n","type":"string"},"vnfcResourceInfo":{"description":"Information about the virtualised compute and storage resources used by the VNFCs of the VNF instance.\n","type":"array","items":{"description":"This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure \n of information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n - For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n - For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\n\n* NOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an internal VL that\n exposes an external CP. A VNFC CP is \"exposed as\" an external CP if it is connected directly\n to an external VL.\n* NOTE 3:\tThe information can be omitted because it is already available as part of the external CP information. * NOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\" structure by \n an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVnfc\"\n structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to \n this LCM operation occurrence.\n* NOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment \n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build \n a link redundant mated pair in SR-IOV cases.\n* NOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. * NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n","type":"object","required":["id","vduId","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"storageResourceIds":{"description":"References to the VirtualStorage resources or references to Storage MCIO(s). The value refers to a VirtualStorageResourceInfo item in the VnfInstance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcCpInfo":{"description":"All the CPs of the VNFC instance. See note 7.\n","type":"array","items":{"type":"object","required":["id","cpdId"],"properties":{"id":{"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"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP. May be omitted if the VNFC CP is exposed as an external CP. The information can be omitted because it is already available as part of the external CP information. See note 3.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"parentCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 5 and 6. It shall be present if the internal CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfVirtualLinkResourceInfo":{"description":"Information about the virtualised network resources used by the VLs of the VNF instance. See note 6. Even though externally-managed internal VLs are also used for VNF-internal connectivity, they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by an internal VL instance in a VNF instance. NOTE: If only the value or the presence of this attribute is changed in the \"VnfVirtualLinkResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a \n related \"AffectedVirtualLink\" structure in the VNF LCM operation occurrence notifications or the \n \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource","vnfLinkPorts"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLinkPorts":{"description":"Links ports of this VL. Shall be present when the linkPort is used for external connectivity by the VNF (refer to VnfLinkPortInfo). May be present otherwise.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualStorageResourceInfo":{"description":"Information on the virtualised storage resource(s) used as storage for the VNF instance.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance.\nNOTE: If only the value or the presence of this attribute is changed in the \"VirtualStorageResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVirtualStorage\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","virtualStorageDescId","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"vnfcInfo":{"description":"Information about the VNFC instances.\n","type":"array","items":{"description":"This type represents the information about a VNFC instance that is part of a VNF instance. * NOTE:\tThis allows to represent the error condition that a VNFC instance has lost its resources.\n","type":"object","required":["id","vduId","vnfcState"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcResourceInfoId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcState":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mcioInfo":{"description":"Information on the MCIO(s) representing VNFC instance(s) realized by one or a set of OS containers and created from the same VDU for the VNF instance.\n","type":"array","items":{"description":"This type provides information about an MCIO representing the set of VNFC instances realized by one or a set of OS containers which have been created based on the same VDU. Within the CISM, an MCIO controller monitors the actual state of an MCIO representing the set of VNFC instances realized by one or a set of OS containers and compare it to the desired state. For an MCIO related to a VDU that has the attribute \"isNumOfInstancesClusterBased\" set to FALSE the desired state is specified in the respective declarative descriptor. For an MCIO related to a VDU that has the attribute \"isNumOfInstancesClusterBased\" set to TRUE, the desired state is determined by the number of CIS-nodes in the cluster that fulfil the VDU requirements. It triggers actions toward the CIS to align the actual to the desired state. Monitoring the actual state includes monitoring the number of MCIO instances available at any specific point in time. In addition, an MCIO controller maintains properties and runtime information on the MCIO instances which have been created based on the same VDU. The McioInfo data structure provides the runtime information on the MCIOs obtained from the MCIO controller.\nNOTE: There are different types of MCIOs. The set of VNFC instances based on the same VDU is represented by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type \n of MCIO, e.g. a POD.\n\nRuntime information of the set of OS containers realizing an individual VNFC instance is not part of the McioInfo data structure; such runtime information is provided in the ResourceHandle data structure referenced from the VnfcResourceInfo. The McioInfo does not provide runtime information of a constituent VNFC instance created based on a specific VDU.\nNOTE 1: The type of MCIO as specified in the declarative descriptor of the MCIO, and that can be read from the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the \n “kind” property of the declarative descriptor.\nNOTE 2: If the attribute additionalInfo is present, it may contain runtime information on the actual and desired state of the MCIO(s). \nNOTE 3: When the container infrastructure service is a Kubernetes® instance, the mcioId is the combined values from the kind and name fields of the Kubernetes resource object, separated by a slash. \n Example: \"Deployment/abcd\". \nNOTE 4: When the container infrastructure service is a Kubernetes® instance, the mcioName is the name field of the resource object.\n","type":"object","required":["mcioId","mcioName","mcioNamespace","vduId","cismId","mcioType","desiredInstances","availableInstances"],"properties":{"mcioId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioName":{"description":"Human readable name of this MCIO. See note 4.\n","type":"string"},"mcioNamespace":{"description":"Namespace of this MCIO.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cismId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioType":{"description":"The type of MCIO. Specific values, their semantics and associated MCIO types are defined in clause 5.5.4.9. Additional values are also permitted. See note 1.\n","type":"string","enum":["Deployment","StatefulSet","DaemonSet"]},"desiredInstances":{"description":"Number of desired MCIO instances.\n","type":"integer"},"availableInstances":{"description":"Number of available MCIO instances.\n","type":"integer"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"vnfPaasServiceInfo":{"description":"Information on the PaaS Services assigned and used by the VNF instance.\n","type":"array","items":{"description":"This type provides information about a PaaS Service that is used by a VNF instance. The PaasServiceInfo is comprised of various sets of information. Some information comes from the VNFD, other information comes from the PaaS Service assets provided by the NFVO to the VNFM, and other information is provided at runtime information about the usage of the PaaS Service.\n","type":"object","required":["id","paasServiceId","paasServiceType","paasServiceRequestId","paasServiceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceType":{"description":"The type of PaaS Service. The value of this attribute is expected to be matched against values of the registered PaaS Services in the PSR.\n","type":"string"},"paasServiceVersion":{"description":"A version.\n","type":"string"},"paasServiceRequestId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"paasServiceHandle":{"description":"This type provides information enabling the access and use of the PaaS Service by the VNF instance. The type and format of the handle depends on the form that the PaaS Service is formed.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"indicators":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"instantiate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"terminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"heal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"operate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"createSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"revertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeCurrentVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"recentVnfLcmOperationLinks":{"description":"Links to the most recent LCM operation occurrences related to this resource. See note 9.\n","type":"object","properties":{"recentVnfLcmOperation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmInstantiation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmTerminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmHeal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmOperate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmModifyInfo":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmCreateSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmRevertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmSelectDplMods":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"VnfInstances.Post.201":{"description":"201 CREATED\nShall be returned when a new \"Individual VNF Instance\" resource and the associated VNF instance identifier\nhas been created successfully. The response body shall contain a representation of the created VNF instance,\nas defined in clause 5.5.2.2. The HTTP response shall include a \"Location\" HTTP header that contains the\nresource URI of the created VNF instance.\n","headers":{"Version":{"description":"The used API version.\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"The resource URI of the created VNF instance\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{"application/json":{"schema":{"description":"This type represents a VNF instance. * NOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist\n between the previous and the newly referred VNF package, i.e. when the new VNFD is\n changed with respect to the previous VNFD in other aspects than merely referencing\n to other VNF software images. In order to avoid misalignment of the VnfInstance with\n the current VNF's on-boarded VNF package, the values of attributes in the VnfInstance\n that have corresponding attributes in the VNFD shall be kept in sync with the values in the VNFD.\n* NOTE 2:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 3:\tThese attributes are sometimes also referred to as configuration parameters\n applicable to a VNF. Some of these are set prior to instantiation and cannot be modified\n if the VNF is instantiated, some are set prior to instantiation (are part of initial configuration)\n and can be modified later, and others can be set only after instantiation.\n The applicability of certain configuration may depend on the VNF and the required operation of\n the VNF at a certain point in time.\n* NOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child\n attributes of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared\n in the VNFD with a defined initial value. The defined initial values can be declared in the VNFD,\n and/or, in case of \"metadata\", obtained from the \"CreateVnfRequest\" structure. Child attributes of\n \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that have no defined initial value shall\n not be created, in order to be consistent with the semantics of the JSON Merge Patch method\n (see IETF RFC 7396) that interprets null values as deletion request.\n* NOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case\n of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding\n to the same VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc\n and externally-managed multi-site VL instance (refer to clause 5.5.3.5).\n* NOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity,\n they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n* NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual extCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the VNF \n LCM operation explicitly indicates the scale level for the aspect.\n* NOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n","type":"object","required":["id","vnfdId","vnfProvider","vnfProductName","vnfSoftwareVersion","vnfdVersion","instantiationState","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceName":{"description":"Name of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfInstanceDescription":{"description":"Human-readable description of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"Provider of the VNF and the VNFD. The value is copied from the VNFD.\n","type":"string"},"vnfProductName":{"description":"Name to identify the VNF Product. The value is copied from the VNFD.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateInfo":{"description":"This type provides input information related to certificate and certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateConfigurationInfo":{"description":"This type provides input information related to certificate management.\n","type":"object","required":["securityPolicy"],"properties":{"certificateBaseProfile":{"description":"This type provides input information to override certificate base profile for certificate management\nNOTE : At least one overriding attributes shall be present, otherwise shall be absent.\n","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"type":"string","description":"Issuer of certificates. See note."},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to subject of certificate.\n* NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of certification target subject FQDN. See note.","type":"string"},"organization":{"description":"Information of certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of certification target subject Country. See note.","type":"string"},"state":{"description":"Information of certification target subject State. See note.","type":"string"},"locality":{"description":"Information of certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"type":"string","description":"Basic constraints of certificates. See note.\n"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [7],clause 7.1.19.4). See note","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}},"securityPolicy":{"description":"Information for security policy to be satisfied for certificate.\n","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"integer"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"integer"}}}},"delegationSupportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"cmfInfo":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["id","endPoint","supportedProtocol"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"endPoint":{"description":"End point of CMF instance.","type":"object","required":["ipAddress","link"],"properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocols":{"description":"Supported protocol by CMF instance.","type":"array","items":{"type":"string","enum":["CMP","CMPv2","EST","SCEP"]}},"certificateChain":{"description":"Certificate chain that this CMF provides.","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"certificateContents":{"description":"Information for contents of issued certificates. The information contained in this attribute may be updated over time during the VNF LCM, e.g. certificate(s) renewal.\n","type":"array","items":{"description":"This type provides input information related to certificate content.\n","type":"object","required":["id","certificateDescId","certificateType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certficateDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"certificateType":{"description":"Type of this certificate.","type":"string","enum":["VNFCI_CERT","VNFOAM_CERT"]},"supportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"version":{"description":"A version.\n","type":"string"},"serialNumber":{"description":"Serial number of this certificate.","type":"integer"},"signatureAlgorithm":{"description":"Algorithm of this certificate's signature.","type":"string"},"issuer":{"description":"Issuer of this certificate.","type":"string"},"notBefore":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"notAfter":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"subject":{"description":"Subject of this certificate.","type":"string"},"publicKeyAlgorithm":{"description":"Algorithm of this certificate's public key.","type":"string"},"publicKey":{"description":"Public key of this certificate.","type":"string"},"certificateExtensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"instantiationState":{"description":"The instantiation state of the VNF.\n","type":"string","enum":["NOT_INSTANTIATED","INSTANTIATED"]},"instantiatedVnfInfo":{"description":"Information specific to an instantiated VNF instance. This attribute shall be present if the instantiateState attribute value is INSTANTIATED.\n","type":"object","required":["flavourId","vnfState","extCpInfo"],"properties":{"flavourId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfState":{"description":"STARTED: The VNF instance is up and running. STOPPED: The VNF instance has been shut down.\n","type":"string","enum":["STARTED","STOPPED"]},"vnfPowerState":{"description":"This type represents information about the power state of a VNF instance.\n","type":"object","required":["powerProfileId","name"],"properties":{"powerProfileId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Name of the power profile as provided in the VNFD.\n","type":"string"},"powerConsumptionInfo":{"description":"This type represents information about estimated power consumption of the resources associated with the power profile, as provided in the VNFD.\n","type":"object","required":["minPowerConsumption","maxPowerConsumption","averagePowerConsumption"],"properties":{"minPowerConsumption":{"description":"Minimum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"maxPowerConsumption":{"description":"Maximum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"averagePowerConsumption":{"description":"Average power consumption of this power profile. Unit is KW/h.\n","type":"integer"}}}}},"scaleStatus":{"description":"Scale status of the VNF, one entry per aspect. Represents for every scaling aspect how \"big\" the VNF has been scaled w.r.t. that aspect. This attribute shall be present if the VNF supports scaling. See clause B.2 for an explanation of VNF scaling. For an aspect that has not been deployed because the related deployableModule has not been selected, it indicates the scale level that has been requested in the instantiation or in a scaling operation, or, if none has been requested in any of them, the scale level applicable to the aspect based on the default instantiation level. See note 8.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleLevel":{"description":"Indicates the scale level. The minimum value shall be 0 and the maximum value shall be <= maxScaleLevel as described in the VNFD.\n","type":"integer"}}}},"maxScaleLevels":{"description":"Maximum allowed scale levels of the VNF, one entry per aspect. This attribute shall be present if the VNF supports scaling.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleLevel":{"description":"Indicates the scale level. The minimum value shall be 0 and the maximum value shall be <= maxScaleLevel as described in the VNFD.\n","type":"integer"}}}},"selectedDeployableModule":{"description":"References a currently selected deployable module, as defined in the VNFD, that has already completed the instantiation of its VNFCs\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceCapacityDefinition":{"description":"Shows current values of VDU attributes related to resource capacity, if different to the default values from the VNFD, as indicated in the (one or more) request(s) of all completed VNF LCM operation(s) that contain this attribute. If an attribute value has been modified multiple times, only the last value is shown. The values indicated in this attribute are applicable to all VNFC instances based on the VDU to which the resourceCapacityDefinition is related.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes. The tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request. At most one tag can be included when the data type is used in a VNF LCM operation request. When the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced. VALUES •\tCOMPUTE •\tSTORAGE •\tOSCONTAINER","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute ‘type’ indicates OSCONTAINER and absent otherwise.","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource.See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resources_property in the VNFD that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["resourceTemplateId"]},{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD for this virtual compute descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"extCpInfo":{"description":"Information about the external CPs exposed by the VNF instance. When trunking is enabled, the list of entries includes both, external CPs corresponding to parent ports of a trunk, and external CPs associated to sub-ports of a trunk. See note 7.\n","type":"array","minItems":1,"items":{"description":"This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n","type":"object","required":["id","cpdId","cpConfigId","cpProtocolInfo"],"oneOf":[{"required":["associatedVnfcCpId"]},{"required":["associatedVipCpId"]},{"required":["associatedVnfVirtualLinkId"]}],"properties":{"id":{"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"},"cpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extLinkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"associatedVnfcCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVipCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVirtualCpId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"associatedVnfVirtualLinkId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 3 and 4. It shall be present if the external CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"certificateContentId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cpSecurityGroupInfo":{"description":"This type provides the list of active security group rules applied to an external CP instance. The type identifies which \"SecurityGroupRule\" specified in the VNFD are activated and the values of its attributes.\n","type":"object","required":["securityGroupRuleId","etherType","protocol","portRangeMin","portRangeMax"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"description":{"description":"Human readable description of the security group rule.\n","type":"string"},"etherType":{"description":"Indicates the protocol carried over the Ethernet layer. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"protocol":{"description":"Indicates the protocol carried over the IP layer. Permitted values: any protocol defined in the IANA protocol registry (refer to clause 9.10.1.2 ofd ETSI GS NFV-SOL 001 for further information).\n","type":"string"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule.\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule.\n","type":"integer"}}}}}},"vipCpInfo":{"description":"VIP CPs that are part of the VNF instance. Shall be present when that particular VIP CP of the VNFC instance is associated to an external CP of the VNF instance.\nMay be present otherwise.\n","type":"array","items":{"description":"This type provides information related to virtual IP CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["cpInstanceId","cpdId"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for layer 3. There may be one cpProtocolInfo for layer 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"associatedVnfcCpIds":{"description":"Identifiers of the VnfcCps that share the virtual IP address allocated to the VIP CP instance. See note.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualCpInfo":{"description":"Virtual CPs that are part of the VNF instance. Shall be present when a particular virtual CP is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","items":{"description":"This type provides information related to a virtual CP instance of a VNF.\n* NOTE 1: A consumer of the VNF LCM interface can learn the actual VNFC instances implementing the service accessible via the virtual CP instance by querying the \"vnfcResourceInfo\" from the \"InstantiatedVnfInfo\" \n and filtering by corresponding \"vduIds\" values.\n* NOTE 2: The information can be omitted because it is already available as part of the external CP information in the VnfExtCpInfo structure.\n","type":"object","required":["cpInstanceId","cpdId","resourceHandle","vduIds"],"properties":{"cpInstanceId":{"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"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for each layer protocol supported. This attribute may be omitted if the virtual CP is exposed as an external CP. See note 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vduIds":{"description":"Reference to the VDU(s) which implement the service accessible via the virtual CP instance. See note.\n","type":"array","minItems":1,"items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"additionalServiceInfo":{"description":"Additional service identification information of the virtual CP instance.\n","type":"array","items":{"description":"This type provides additional service information of the virtual CP instance used to expose properties of the virtual CP to NFV-MANO.\nNOTE: This attribute shall only be present if additional information is needed to identify the service termination within the VNF, such as for example a URL path information in an HTTP request required \n to allow a single virtual CP IP address to be used for several HTTP based services that use the \n same port number.\n","type":"object","required":["portInfo"],"properties":{"portInfo":{"description":"Service port numbers exposed by the virtual CP instance.\n","minItems":1,"type":"array","items":{"description":"This type describes the service identifying port properties exposed by the virtual CP instance.\n","type":"object","required":["name","port","portConfigurable"],"properties":{"name":{"description":"The name of the port exposed by the virtual CP instance.\n","type":"string"},"protocol":{"description":"The L4 protocol for this port exposed by the virtual CP instance.\nPermitted values: - TCP - UDP - SCTP\n","type":"string","enum":["TCP","UDP","SCTP"]},"port":{"description":"The L4 port number exposed by the virtual CP instance.\n","type":"integer"},"portConfigurable":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"}}}},"serviceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"extVirtualLinkInfo":{"description":"Information about the external VLs the VNF instance is connected to.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD. The key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO. The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5 and 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored.\n\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for \n Kubernetes® that supports configuration of address pools for load balancer services.\n\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"string"},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"string"}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"routingResource":{"description":"Network resources that provide the forwarding/routing capabilities associated to the network resource realizing this VL.\n","type":"array","items":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}}},"extManagedVirtualLinkInfo":{"description":"Information about the externally managed internal VLs of the VNF instance. See note 5 and note 6. It is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed multi-site VL instance (refer to clause 5.5.3.5). Even though externally-managed internal VLs are also used for VNF-internal connectivity, they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n","type":"array","items":{"description":"This type provides information about an externally-managed virtual link. *NOTE: Both vnfLinkPort and vnfNetAttDefResource can be present in an ExtManagedVirtualLinkInfo to indicate that a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPorts":{"description":"Link ports of this VL.See note.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"vnfNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"routingResource":{"description":"Network resources that provide the forwarding/routing capabilities associated to the network resource realizing this VL.\n","type":"array","items":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}}},"monitoringParameters":{"description":"Active monitoring parameters.\n","type":"array","items":{"type":"object","required":["id","performanceMetric"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human readable name of the monitoring parameter, as defined in the VNFD.\n","type":"string"},"performanceMetric":{"description":"Performance metric that is monitored. This attribute shall contain the related \"Measurement Name\" value as defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"}}}},"localizationLanguage":{"description":"Information about localization language of the VNF (includes e.g. strings in the VNFD). The localization languages supported by a VNF can be declared in the VNFD, and localization language selection can take place at instantiation time. The value shall comply with the format defined in IETF RFC 5646.\n","type":"string"},"vnfcResourceInfo":{"description":"Information about the virtualised compute and storage resources used by the VNFCs of the VNF instance.\n","type":"array","items":{"description":"This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure \n of information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n - For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n - For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\n\n* NOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an internal VL that\n exposes an external CP. A VNFC CP is \"exposed as\" an external CP if it is connected directly\n to an external VL.\n* NOTE 3:\tThe information can be omitted because it is already available as part of the external CP information. * NOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\" structure by \n an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVnfc\"\n structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to \n this LCM operation occurrence.\n* NOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment \n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build \n a link redundant mated pair in SR-IOV cases.\n* NOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. * NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n","type":"object","required":["id","vduId","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"storageResourceIds":{"description":"References to the VirtualStorage resources or references to Storage MCIO(s). The value refers to a VirtualStorageResourceInfo item in the VnfInstance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcCpInfo":{"description":"All the CPs of the VNFC instance. See note 7.\n","type":"array","items":{"type":"object","required":["id","cpdId"],"properties":{"id":{"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"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP. May be omitted if the VNFC CP is exposed as an external CP. The information can be omitted because it is already available as part of the external CP information. See note 3.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"parentCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 5 and 6. It shall be present if the internal CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfVirtualLinkResourceInfo":{"description":"Information about the virtualised network resources used by the VLs of the VNF instance. See note 6. Even though externally-managed internal VLs are also used for VNF-internal connectivity, they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by an internal VL instance in a VNF instance. NOTE: If only the value or the presence of this attribute is changed in the \"VnfVirtualLinkResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a \n related \"AffectedVirtualLink\" structure in the VNF LCM operation occurrence notifications or the \n \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource","vnfLinkPorts"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLinkPorts":{"description":"Links ports of this VL. Shall be present when the linkPort is used for external connectivity by the VNF (refer to VnfLinkPortInfo). May be present otherwise.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualStorageResourceInfo":{"description":"Information on the virtualised storage resource(s) used as storage for the VNF instance.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance.\nNOTE: If only the value or the presence of this attribute is changed in the \"VirtualStorageResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVirtualStorage\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","virtualStorageDescId","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"vnfcInfo":{"description":"Information about the VNFC instances.\n","type":"array","items":{"description":"This type represents the information about a VNFC instance that is part of a VNF instance. * NOTE:\tThis allows to represent the error condition that a VNFC instance has lost its resources.\n","type":"object","required":["id","vduId","vnfcState"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcResourceInfoId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcState":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mcioInfo":{"description":"Information on the MCIO(s) representing VNFC instance(s) realized by one or a set of OS containers and created from the same VDU for the VNF instance.\n","type":"array","items":{"description":"This type provides information about an MCIO representing the set of VNFC instances realized by one or a set of OS containers which have been created based on the same VDU. Within the CISM, an MCIO controller monitors the actual state of an MCIO representing the set of VNFC instances realized by one or a set of OS containers and compare it to the desired state. For an MCIO related to a VDU that has the attribute \"isNumOfInstancesClusterBased\" set to FALSE the desired state is specified in the respective declarative descriptor. For an MCIO related to a VDU that has the attribute \"isNumOfInstancesClusterBased\" set to TRUE, the desired state is determined by the number of CIS-nodes in the cluster that fulfil the VDU requirements. It triggers actions toward the CIS to align the actual to the desired state. Monitoring the actual state includes monitoring the number of MCIO instances available at any specific point in time. In addition, an MCIO controller maintains properties and runtime information on the MCIO instances which have been created based on the same VDU. The McioInfo data structure provides the runtime information on the MCIOs obtained from the MCIO controller.\nNOTE: There are different types of MCIOs. The set of VNFC instances based on the same VDU is represented by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type \n of MCIO, e.g. a POD.\n\nRuntime information of the set of OS containers realizing an individual VNFC instance is not part of the McioInfo data structure; such runtime information is provided in the ResourceHandle data structure referenced from the VnfcResourceInfo. The McioInfo does not provide runtime information of a constituent VNFC instance created based on a specific VDU.\nNOTE 1: The type of MCIO as specified in the declarative descriptor of the MCIO, and that can be read from the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the \n “kind” property of the declarative descriptor.\nNOTE 2: If the attribute additionalInfo is present, it may contain runtime information on the actual and desired state of the MCIO(s). \nNOTE 3: When the container infrastructure service is a Kubernetes® instance, the mcioId is the combined values from the kind and name fields of the Kubernetes resource object, separated by a slash. \n Example: \"Deployment/abcd\". \nNOTE 4: When the container infrastructure service is a Kubernetes® instance, the mcioName is the name field of the resource object.\n","type":"object","required":["mcioId","mcioName","mcioNamespace","vduId","cismId","mcioType","desiredInstances","availableInstances"],"properties":{"mcioId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioName":{"description":"Human readable name of this MCIO. See note 4.\n","type":"string"},"mcioNamespace":{"description":"Namespace of this MCIO.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cismId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioType":{"description":"The type of MCIO. Specific values, their semantics and associated MCIO types are defined in clause 5.5.4.9. Additional values are also permitted. See note 1.\n","type":"string","enum":["Deployment","StatefulSet","DaemonSet"]},"desiredInstances":{"description":"Number of desired MCIO instances.\n","type":"integer"},"availableInstances":{"description":"Number of available MCIO instances.\n","type":"integer"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"vnfPaasServiceInfo":{"description":"Information on the PaaS Services assigned and used by the VNF instance.\n","type":"array","items":{"description":"This type provides information about a PaaS Service that is used by a VNF instance. The PaasServiceInfo is comprised of various sets of information. Some information comes from the VNFD, other information comes from the PaaS Service assets provided by the NFVO to the VNFM, and other information is provided at runtime information about the usage of the PaaS Service.\n","type":"object","required":["id","paasServiceId","paasServiceType","paasServiceRequestId","paasServiceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceType":{"description":"The type of PaaS Service. The value of this attribute is expected to be matched against values of the registered PaaS Services in the PSR.\n","type":"string"},"paasServiceVersion":{"description":"A version.\n","type":"string"},"paasServiceRequestId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"paasServiceHandle":{"description":"This type provides information enabling the access and use of the PaaS Service by the VNF instance. The type and format of the handle depends on the form that the PaaS Service is formed.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"indicators":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"instantiate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"terminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"heal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"operate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"createSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"revertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeCurrentVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"recentVnfLcmOperationLinks":{"description":"Links to the most recent LCM operation occurrences related to this resource. See note 9.\n","type":"object","properties":{"recentVnfLcmOperation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmInstantiation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmTerminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmHeal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmOperate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmModifyInfo":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmCreateSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmRevertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmSelectDplMods":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"VnfInstances.Post.422":{"description":"422 Unprocessable Content\n\nShall be returned upon the following error: The content type of the message content is supported and the\nmessage content of a request contains syntactically correct data but the data cannot be processed.\nThe general cause for this error and its handling is specified in clause 6.4 of ETSI GS NFV-SOL 013,\nincluding rules for the presence of the response body.\nSpecifically in case of this resource, the response code 422 shall also be returned if the VNF package\nreferenced by the \"vnfdId\" attribute in the \"CreateVnfRequest\" structure is not in the \"ENABLED\"\nstate or does not exist. In this case, the \"detail\" attribute in the \"ProblemDetails\" structure shall convey\nmore information about the error.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualVnfInstance.Get.200":{"description":"200 OK\nInformation about an individual VNF instance has been read successfully. The response body shall contain a\nrepresentation of the VNF instance, as defined in clause 5.5.2.2.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"ETag":{"description":"Used to provide the current entity-tag for the selected resource representation. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string"}},"Last-Modified":{"description":"Used to provide a timestamp indicating the date and time at which the server believes the selected resource representation was last modified. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string","format":"date-time"}}},"content":{"application/json":{"schema":{"description":"This type represents a VNF instance. * NOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist\n between the previous and the newly referred VNF package, i.e. when the new VNFD is\n changed with respect to the previous VNFD in other aspects than merely referencing\n to other VNF software images. In order to avoid misalignment of the VnfInstance with\n the current VNF's on-boarded VNF package, the values of attributes in the VnfInstance\n that have corresponding attributes in the VNFD shall be kept in sync with the values in the VNFD.\n* NOTE 2:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 3:\tThese attributes are sometimes also referred to as configuration parameters\n applicable to a VNF. Some of these are set prior to instantiation and cannot be modified\n if the VNF is instantiated, some are set prior to instantiation (are part of initial configuration)\n and can be modified later, and others can be set only after instantiation.\n The applicability of certain configuration may depend on the VNF and the required operation of\n the VNF at a certain point in time.\n* NOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child\n attributes of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared\n in the VNFD with a defined initial value. The defined initial values can be declared in the VNFD,\n and/or, in case of \"metadata\", obtained from the \"CreateVnfRequest\" structure. Child attributes of\n \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that have no defined initial value shall\n not be created, in order to be consistent with the semantics of the JSON Merge Patch method\n (see IETF RFC 7396) that interprets null values as deletion request.\n* NOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case\n of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding\n to the same VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc\n and externally-managed multi-site VL instance (refer to clause 5.5.3.5).\n* NOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity,\n they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n* NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual extCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the VNF \n LCM operation explicitly indicates the scale level for the aspect.\n* NOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n","type":"object","required":["id","vnfdId","vnfProvider","vnfProductName","vnfSoftwareVersion","vnfdVersion","instantiationState","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceName":{"description":"Name of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfInstanceDescription":{"description":"Human-readable description of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"Provider of the VNF and the VNFD. The value is copied from the VNFD.\n","type":"string"},"vnfProductName":{"description":"Name to identify the VNF Product. The value is copied from the VNFD.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateInfo":{"description":"This type provides input information related to certificate and certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateConfigurationInfo":{"description":"This type provides input information related to certificate management.\n","type":"object","required":["securityPolicy"],"properties":{"certificateBaseProfile":{"description":"This type provides input information to override certificate base profile for certificate management\nNOTE : At least one overriding attributes shall be present, otherwise shall be absent.\n","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"type":"string","description":"Issuer of certificates. See note."},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to subject of certificate.\n* NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of certification target subject FQDN. See note.","type":"string"},"organization":{"description":"Information of certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of certification target subject Country. See note.","type":"string"},"state":{"description":"Information of certification target subject State. See note.","type":"string"},"locality":{"description":"Information of certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"type":"string","description":"Basic constraints of certificates. See note.\n"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [7],clause 7.1.19.4). See note","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}},"securityPolicy":{"description":"Information for security policy to be satisfied for certificate.\n","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"integer"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"integer"}}}},"delegationSupportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"cmfInfo":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["id","endPoint","supportedProtocol"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"endPoint":{"description":"End point of CMF instance.","type":"object","required":["ipAddress","link"],"properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocols":{"description":"Supported protocol by CMF instance.","type":"array","items":{"type":"string","enum":["CMP","CMPv2","EST","SCEP"]}},"certificateChain":{"description":"Certificate chain that this CMF provides.","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"certificateContents":{"description":"Information for contents of issued certificates. The information contained in this attribute may be updated over time during the VNF LCM, e.g. certificate(s) renewal.\n","type":"array","items":{"description":"This type provides input information related to certificate content.\n","type":"object","required":["id","certificateDescId","certificateType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certficateDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"certificateType":{"description":"Type of this certificate.","type":"string","enum":["VNFCI_CERT","VNFOAM_CERT"]},"supportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"version":{"description":"A version.\n","type":"string"},"serialNumber":{"description":"Serial number of this certificate.","type":"integer"},"signatureAlgorithm":{"description":"Algorithm of this certificate's signature.","type":"string"},"issuer":{"description":"Issuer of this certificate.","type":"string"},"notBefore":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"notAfter":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"subject":{"description":"Subject of this certificate.","type":"string"},"publicKeyAlgorithm":{"description":"Algorithm of this certificate's public key.","type":"string"},"publicKey":{"description":"Public key of this certificate.","type":"string"},"certificateExtensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"instantiationState":{"description":"The instantiation state of the VNF.\n","type":"string","enum":["NOT_INSTANTIATED","INSTANTIATED"]},"instantiatedVnfInfo":{"description":"Information specific to an instantiated VNF instance. This attribute shall be present if the instantiateState attribute value is INSTANTIATED.\n","type":"object","required":["flavourId","vnfState","extCpInfo"],"properties":{"flavourId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfState":{"description":"STARTED: The VNF instance is up and running. STOPPED: The VNF instance has been shut down.\n","type":"string","enum":["STARTED","STOPPED"]},"vnfPowerState":{"description":"This type represents information about the power state of a VNF instance.\n","type":"object","required":["powerProfileId","name"],"properties":{"powerProfileId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Name of the power profile as provided in the VNFD.\n","type":"string"},"powerConsumptionInfo":{"description":"This type represents information about estimated power consumption of the resources associated with the power profile, as provided in the VNFD.\n","type":"object","required":["minPowerConsumption","maxPowerConsumption","averagePowerConsumption"],"properties":{"minPowerConsumption":{"description":"Minimum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"maxPowerConsumption":{"description":"Maximum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"averagePowerConsumption":{"description":"Average power consumption of this power profile. Unit is KW/h.\n","type":"integer"}}}}},"scaleStatus":{"description":"Scale status of the VNF, one entry per aspect. Represents for every scaling aspect how \"big\" the VNF has been scaled w.r.t. that aspect. This attribute shall be present if the VNF supports scaling. See clause B.2 for an explanation of VNF scaling. For an aspect that has not been deployed because the related deployableModule has not been selected, it indicates the scale level that has been requested in the instantiation or in a scaling operation, or, if none has been requested in any of them, the scale level applicable to the aspect based on the default instantiation level. See note 8.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleLevel":{"description":"Indicates the scale level. The minimum value shall be 0 and the maximum value shall be <= maxScaleLevel as described in the VNFD.\n","type":"integer"}}}},"maxScaleLevels":{"description":"Maximum allowed scale levels of the VNF, one entry per aspect. This attribute shall be present if the VNF supports scaling.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleLevel":{"description":"Indicates the scale level. The minimum value shall be 0 and the maximum value shall be <= maxScaleLevel as described in the VNFD.\n","type":"integer"}}}},"selectedDeployableModule":{"description":"References a currently selected deployable module, as defined in the VNFD, that has already completed the instantiation of its VNFCs\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceCapacityDefinition":{"description":"Shows current values of VDU attributes related to resource capacity, if different to the default values from the VNFD, as indicated in the (one or more) request(s) of all completed VNF LCM operation(s) that contain this attribute. If an attribute value has been modified multiple times, only the last value is shown. The values indicated in this attribute are applicable to all VNFC instances based on the VDU to which the resourceCapacityDefinition is related.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes. The tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request. At most one tag can be included when the data type is used in a VNF LCM operation request. When the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced. VALUES •\tCOMPUTE •\tSTORAGE •\tOSCONTAINER","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute ‘type’ indicates OSCONTAINER and absent otherwise.","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource.See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resources_property in the VNFD that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["resourceTemplateId"]},{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD for this virtual compute descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"extCpInfo":{"description":"Information about the external CPs exposed by the VNF instance. When trunking is enabled, the list of entries includes both, external CPs corresponding to parent ports of a trunk, and external CPs associated to sub-ports of a trunk. See note 7.\n","type":"array","minItems":1,"items":{"description":"This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n","type":"object","required":["id","cpdId","cpConfigId","cpProtocolInfo"],"oneOf":[{"required":["associatedVnfcCpId"]},{"required":["associatedVipCpId"]},{"required":["associatedVnfVirtualLinkId"]}],"properties":{"id":{"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"},"cpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extLinkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"associatedVnfcCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVipCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVirtualCpId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"associatedVnfVirtualLinkId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 3 and 4. It shall be present if the external CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"certificateContentId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cpSecurityGroupInfo":{"description":"This type provides the list of active security group rules applied to an external CP instance. The type identifies which \"SecurityGroupRule\" specified in the VNFD are activated and the values of its attributes.\n","type":"object","required":["securityGroupRuleId","etherType","protocol","portRangeMin","portRangeMax"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"description":{"description":"Human readable description of the security group rule.\n","type":"string"},"etherType":{"description":"Indicates the protocol carried over the Ethernet layer. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"protocol":{"description":"Indicates the protocol carried over the IP layer. Permitted values: any protocol defined in the IANA protocol registry (refer to clause 9.10.1.2 ofd ETSI GS NFV-SOL 001 for further information).\n","type":"string"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule.\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule.\n","type":"integer"}}}}}},"vipCpInfo":{"description":"VIP CPs that are part of the VNF instance. Shall be present when that particular VIP CP of the VNFC instance is associated to an external CP of the VNF instance.\nMay be present otherwise.\n","type":"array","items":{"description":"This type provides information related to virtual IP CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["cpInstanceId","cpdId"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for layer 3. There may be one cpProtocolInfo for layer 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"associatedVnfcCpIds":{"description":"Identifiers of the VnfcCps that share the virtual IP address allocated to the VIP CP instance. See note.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualCpInfo":{"description":"Virtual CPs that are part of the VNF instance. Shall be present when a particular virtual CP is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","items":{"description":"This type provides information related to a virtual CP instance of a VNF.\n* NOTE 1: A consumer of the VNF LCM interface can learn the actual VNFC instances implementing the service accessible via the virtual CP instance by querying the \"vnfcResourceInfo\" from the \"InstantiatedVnfInfo\" \n and filtering by corresponding \"vduIds\" values.\n* NOTE 2: The information can be omitted because it is already available as part of the external CP information in the VnfExtCpInfo structure.\n","type":"object","required":["cpInstanceId","cpdId","resourceHandle","vduIds"],"properties":{"cpInstanceId":{"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"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for each layer protocol supported. This attribute may be omitted if the virtual CP is exposed as an external CP. See note 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vduIds":{"description":"Reference to the VDU(s) which implement the service accessible via the virtual CP instance. See note.\n","type":"array","minItems":1,"items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"additionalServiceInfo":{"description":"Additional service identification information of the virtual CP instance.\n","type":"array","items":{"description":"This type provides additional service information of the virtual CP instance used to expose properties of the virtual CP to NFV-MANO.\nNOTE: This attribute shall only be present if additional information is needed to identify the service termination within the VNF, such as for example a URL path information in an HTTP request required \n to allow a single virtual CP IP address to be used for several HTTP based services that use the \n same port number.\n","type":"object","required":["portInfo"],"properties":{"portInfo":{"description":"Service port numbers exposed by the virtual CP instance.\n","minItems":1,"type":"array","items":{"description":"This type describes the service identifying port properties exposed by the virtual CP instance.\n","type":"object","required":["name","port","portConfigurable"],"properties":{"name":{"description":"The name of the port exposed by the virtual CP instance.\n","type":"string"},"protocol":{"description":"The L4 protocol for this port exposed by the virtual CP instance.\nPermitted values: - TCP - UDP - SCTP\n","type":"string","enum":["TCP","UDP","SCTP"]},"port":{"description":"The L4 port number exposed by the virtual CP instance.\n","type":"integer"},"portConfigurable":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"}}}},"serviceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"extVirtualLinkInfo":{"description":"Information about the external VLs the VNF instance is connected to.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD. The key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO. The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5 and 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored.\n\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for \n Kubernetes® that supports configuration of address pools for load balancer services.\n\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"string"},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"string"}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"routingResource":{"description":"Network resources that provide the forwarding/routing capabilities associated to the network resource realizing this VL.\n","type":"array","items":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}}},"extManagedVirtualLinkInfo":{"description":"Information about the externally managed internal VLs of the VNF instance. See note 5 and note 6. It is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed multi-site VL instance (refer to clause 5.5.3.5). Even though externally-managed internal VLs are also used for VNF-internal connectivity, they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n","type":"array","items":{"description":"This type provides information about an externally-managed virtual link. *NOTE: Both vnfLinkPort and vnfNetAttDefResource can be present in an ExtManagedVirtualLinkInfo to indicate that a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPorts":{"description":"Link ports of this VL.See note.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"vnfNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"routingResource":{"description":"Network resources that provide the forwarding/routing capabilities associated to the network resource realizing this VL.\n","type":"array","items":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}}},"monitoringParameters":{"description":"Active monitoring parameters.\n","type":"array","items":{"type":"object","required":["id","performanceMetric"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human readable name of the monitoring parameter, as defined in the VNFD.\n","type":"string"},"performanceMetric":{"description":"Performance metric that is monitored. This attribute shall contain the related \"Measurement Name\" value as defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"}}}},"localizationLanguage":{"description":"Information about localization language of the VNF (includes e.g. strings in the VNFD). The localization languages supported by a VNF can be declared in the VNFD, and localization language selection can take place at instantiation time. The value shall comply with the format defined in IETF RFC 5646.\n","type":"string"},"vnfcResourceInfo":{"description":"Information about the virtualised compute and storage resources used by the VNFCs of the VNF instance.\n","type":"array","items":{"description":"This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure \n of information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n - For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n - For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\n\n* NOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an internal VL that\n exposes an external CP. A VNFC CP is \"exposed as\" an external CP if it is connected directly\n to an external VL.\n* NOTE 3:\tThe information can be omitted because it is already available as part of the external CP information. * NOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\" structure by \n an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVnfc\"\n structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to \n this LCM operation occurrence.\n* NOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment \n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build \n a link redundant mated pair in SR-IOV cases.\n* NOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. * NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n","type":"object","required":["id","vduId","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"storageResourceIds":{"description":"References to the VirtualStorage resources or references to Storage MCIO(s). The value refers to a VirtualStorageResourceInfo item in the VnfInstance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcCpInfo":{"description":"All the CPs of the VNFC instance. See note 7.\n","type":"array","items":{"type":"object","required":["id","cpdId"],"properties":{"id":{"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"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP. May be omitted if the VNFC CP is exposed as an external CP. The information can be omitted because it is already available as part of the external CP information. See note 3.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"parentCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 5 and 6. It shall be present if the internal CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfVirtualLinkResourceInfo":{"description":"Information about the virtualised network resources used by the VLs of the VNF instance. See note 6. Even though externally-managed internal VLs are also used for VNF-internal connectivity, they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by an internal VL instance in a VNF instance. NOTE: If only the value or the presence of this attribute is changed in the \"VnfVirtualLinkResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a \n related \"AffectedVirtualLink\" structure in the VNF LCM operation occurrence notifications or the \n \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource","vnfLinkPorts"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLinkPorts":{"description":"Links ports of this VL. Shall be present when the linkPort is used for external connectivity by the VNF (refer to VnfLinkPortInfo). May be present otherwise.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualStorageResourceInfo":{"description":"Information on the virtualised storage resource(s) used as storage for the VNF instance.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance.\nNOTE: If only the value or the presence of this attribute is changed in the \"VirtualStorageResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVirtualStorage\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","virtualStorageDescId","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"vnfcInfo":{"description":"Information about the VNFC instances.\n","type":"array","items":{"description":"This type represents the information about a VNFC instance that is part of a VNF instance. * NOTE:\tThis allows to represent the error condition that a VNFC instance has lost its resources.\n","type":"object","required":["id","vduId","vnfcState"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcResourceInfoId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcState":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mcioInfo":{"description":"Information on the MCIO(s) representing VNFC instance(s) realized by one or a set of OS containers and created from the same VDU for the VNF instance.\n","type":"array","items":{"description":"This type provides information about an MCIO representing the set of VNFC instances realized by one or a set of OS containers which have been created based on the same VDU. Within the CISM, an MCIO controller monitors the actual state of an MCIO representing the set of VNFC instances realized by one or a set of OS containers and compare it to the desired state. For an MCIO related to a VDU that has the attribute \"isNumOfInstancesClusterBased\" set to FALSE the desired state is specified in the respective declarative descriptor. For an MCIO related to a VDU that has the attribute \"isNumOfInstancesClusterBased\" set to TRUE, the desired state is determined by the number of CIS-nodes in the cluster that fulfil the VDU requirements. It triggers actions toward the CIS to align the actual to the desired state. Monitoring the actual state includes monitoring the number of MCIO instances available at any specific point in time. In addition, an MCIO controller maintains properties and runtime information on the MCIO instances which have been created based on the same VDU. The McioInfo data structure provides the runtime information on the MCIOs obtained from the MCIO controller.\nNOTE: There are different types of MCIOs. The set of VNFC instances based on the same VDU is represented by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type \n of MCIO, e.g. a POD.\n\nRuntime information of the set of OS containers realizing an individual VNFC instance is not part of the McioInfo data structure; such runtime information is provided in the ResourceHandle data structure referenced from the VnfcResourceInfo. The McioInfo does not provide runtime information of a constituent VNFC instance created based on a specific VDU.\nNOTE 1: The type of MCIO as specified in the declarative descriptor of the MCIO, and that can be read from the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the \n “kind” property of the declarative descriptor.\nNOTE 2: If the attribute additionalInfo is present, it may contain runtime information on the actual and desired state of the MCIO(s). \nNOTE 3: When the container infrastructure service is a Kubernetes® instance, the mcioId is the combined values from the kind and name fields of the Kubernetes resource object, separated by a slash. \n Example: \"Deployment/abcd\". \nNOTE 4: When the container infrastructure service is a Kubernetes® instance, the mcioName is the name field of the resource object.\n","type":"object","required":["mcioId","mcioName","mcioNamespace","vduId","cismId","mcioType","desiredInstances","availableInstances"],"properties":{"mcioId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioName":{"description":"Human readable name of this MCIO. See note 4.\n","type":"string"},"mcioNamespace":{"description":"Namespace of this MCIO.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cismId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioType":{"description":"The type of MCIO. Specific values, their semantics and associated MCIO types are defined in clause 5.5.4.9. Additional values are also permitted. See note 1.\n","type":"string","enum":["Deployment","StatefulSet","DaemonSet"]},"desiredInstances":{"description":"Number of desired MCIO instances.\n","type":"integer"},"availableInstances":{"description":"Number of available MCIO instances.\n","type":"integer"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"vnfPaasServiceInfo":{"description":"Information on the PaaS Services assigned and used by the VNF instance.\n","type":"array","items":{"description":"This type provides information about a PaaS Service that is used by a VNF instance. The PaasServiceInfo is comprised of various sets of information. Some information comes from the VNFD, other information comes from the PaaS Service assets provided by the NFVO to the VNFM, and other information is provided at runtime information about the usage of the PaaS Service.\n","type":"object","required":["id","paasServiceId","paasServiceType","paasServiceRequestId","paasServiceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceType":{"description":"The type of PaaS Service. The value of this attribute is expected to be matched against values of the registered PaaS Services in the PSR.\n","type":"string"},"paasServiceVersion":{"description":"A version.\n","type":"string"},"paasServiceRequestId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"paasServiceHandle":{"description":"This type provides information enabling the access and use of the PaaS Service by the VNF instance. The type and format of the handle depends on the form that the PaaS Service is formed.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"indicators":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"instantiate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"terminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"heal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"operate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"createSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"revertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeCurrentVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"recentVnfLcmOperationLinks":{"description":"Links to the most recent LCM operation occurrences related to this resource. See note 9.\n","type":"object","properties":{"recentVnfLcmOperation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmInstantiation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmTerminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmHeal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmOperate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmModifyInfo":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmCreateSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmRevertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmSelectDplMods":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualVnfInstance.Delete.204":{"description":"204 NO CONTENT\nThe \"Individual VNF instance\" resource and the associated VNF identifier were deleted successfully.\nThe response body shall be empty.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a VNF identifier deletion notification, which informs the receiver of the deletion of a new \"Individual VNF instance\" resource and the associated VNF instance identifier. This notification shall be triggered by the VNFM when it has deleted an \"Individual VNF instance\" resource and the associated VNF instance identifier.\n","type":"object","required":["id","notificationType","subscriptionId","timeStamp","vnfInstanceId","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"VnfIdentifierDeletionNotification\" for this notification type.\n","type":"string","enum":["VnfIdentifierDeletionNotification"]},"subscriptionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"_links":{"description":"This type represents the links to resources that a notification can contain.\n","type":"object","required":["vnfInstance","subscription"],"properties":{"vnfInstance":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"subscription":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfLcmOpOcc":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualVnfInstance.Delete.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the \"Individual\nVNF instance\" resource is in INSTANTIATED state.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualVnfInstance.Patch.202":{"description":"202 ACCEPTED\nThe request was accepted for processing, but the processing has not been completed. On success, the HTTP\nresponse shall include a \"Location\" HTTP header that contains the URI of the newly-created an \"Individual\nVNF LCM operation occurrence\" resource corresponding to the operation. The response body shall be empty.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"Used in redirection, or when a new resource has been created. This header field shall be present if the\nresponse status code is 201 or 3xx. In the present document this header field is also used if the response\nstatus code is 202 and a new resource was created.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{}},"IndividualVnfInstance.Patch.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the \"Individual VNF instance\"\nresource\nTypically, this is due to the fact that another LCM\noperation is ongoing.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute should convey\nmore information about the error\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"InstantiateVnfInstance.Post.202":{"description":"202 ACCEPTED\nThe request has been accepted for processing, but the processing has not been completed. The response body\nshall be empty. The HTTP response shall include a \"Location\" HTTP header that contains the URI of the\nnewly-created \"VNF LCM operation occurrence\" resource corresponding to the operation.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"Used in redirection, or when a new resource has been created. This header field shall be present if the\nresponse status code is 201 or 3xx. In the present document this header field is also used if the response\nstatus code is 202 and a new resource was created.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{}},"InstantiateVnfInstance.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the \"Individual\nVNF instance\" resource is in INSTANTIATED state\nor that a required (see note) child attribute of the\n\"extensions\" attribute has not been set.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"ScaleVnfInstance.Post.202":{"description":"202 ACCEPTED\nThe request has been accepted for processing, but the processing has not been completed. The response body\nshall be empty. The HTTP response shall include a \"Location\" HTTP header that contains the URI of the\nnewly-created \"Individual VNF LCM operation occurrence\" resource corresponding to the operation.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"Used in redirection, or when a new resource has been created. This header field shall be present if the\nresponse status code is 201 or 3xx. In the present document this header field is also used if the response\nstatus code is 202 and a new resource was created.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{}},"ScaleVnfInstance.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the \"Individual\nVNF instance\" resource is in NOT_INSTANTIATED\nstate, that another lifecycle management operation is\nongoing, or that a required (see note) child attribute\nof the \"extensions\" attribute has not been set.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"ScaleVnfInstanceToLevel.Post.202":{"description":"202 ACCEPTED\nThe request has been accepted for processing, but the processing has not been completed. The response body shall\nbe empty. The HTTP response shall include a \"Location\" HTTP header that contains the URI of the newly-created\n\"VNF LCM operation occurrence\" resource corresponding to the operation.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"Used in redirection, or when a new resource has been created. This header field shall be present if the\nresponse status code is 201 or 3xx. In the present document this header field is also used if the response\nstatus code is 202 and a new resource was created.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{}},"ScaleVnfInstanceToLevel.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the VNF instance\nresource is in NOT_INSTANTIATED state, that\nanother lifecycle management operation is ongoing,\nor that a required (see note) child attribute of the\n\"extensions\" attribute has not been set.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\nNote: Required attributes are marked as \"required\" in the VNFD.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"VnfInstanceChangeFlavour.Post.202":{"description":"202 ACCEPTED\nThe request has been accepted for processing, but the processing has not been completed. The response body\nshall be empty. The HTTP response shall include a \"Location\" HTTP header that contains the URI of the\nnewly-created \"Individual VNF LCM operation occurrence\" resource corresponding to the operation.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"Used in redirection, or when a new resource has been created. This header field shall be present if the\nresponse status code is 201 or 3xx. In the present document this header field is also used if the response\nstatus code is 202 and a new resource was created.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{}},"VnfInstanceChangeFlavour.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the\n\"Individual VNF instance\" resource is in\nNOT_INSTANTIATED state, that another\nlifecycle management operation is ongoing, or\nthat a required (see note) child attribute of the\n\"extensions\" attribute has not been set.\nThe response body shall contain a\nProblemDetails structure, in which the \"detail\"\nattribute shall convey more information about the\nerror.\nnote: Required attributes are marked as \"required\" in the VNFD.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"TerminateVnfInstance.Post.202":{"description":"202 ACCEPTED\nThe request has been accepted for processing. The response body shall be empty. The HTTP response shall include\na \"Location\" HTTP header that contains the URI of the newly-created \"Individual VNF LCM operation occurrence\"\nresource corresponding to the operation.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"Used in redirection, or when a new resource has been created. This header field shall be present if the\nresponse status code is 201 or 3xx. In the present document this header field is also used if the response\nstatus code is 202 and a new resource was created.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{}},"TerminateVnfInstance.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the \"Individual VNF\ninstance\" resource is in NOT_INSTANTIATED state, or\nthat another lifecycle management operation is\nongoing, or that a required (see note) child attribute of\nthe \"extensions\" attribute has not been set.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\nnote: Required attributes are marked as \"required\" in the VNFD.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"HealVnfInstance.Post.202":{"description":"202 ACCEPTED\nThe request has been accepted for processing, but the processing has not been completed. The response body\nshall be empty. The HTTP response shall include a \"Location\" HTTP header that contains the URI of the\nnewly-created \"Individual VNF LCM operation occurrence\" resource corresponding to the operation.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"Used in redirection, or when a new resource has been created. This header field shall be present if the\nresponse status code is 201 or 3xx. In the present document this header field is also used if the response\nstatus code is 202 and a new resource was created.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{}},"HealVnfInstance.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the \"Individual VNF\ninstance\" resource is in NOT_INSTANTIATED state,\nthat another lifecycle management operation is\nongoing, or that a required (see note) child attribute of\nthe \"extensions\" attribute has not been set.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\nnote: Required attributes are marked as \"required\" in the VNFD.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"OperateVnfInstance.Post.202":{"description":"202 ACCEPTED\nThe request has been accepted for processing, but the processing has not been completed. The response body\nshall be empty. The HTTP response shall include a \"Location\" HTTP header that contains the URI of the\nnewly-created \"VNF LCM operation occurrence\" resource corresponding to the operation.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"Used in redirection, or when a new resource has been created. This header field shall be present if the\nresponse status code is 201 or 3xx. In the present document this header field is also used if the response\nstatus code is 202 and a new resource was created.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{}},"OperateVnfInstance.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the \"Individual VNF\ninstance\" resource is in NOT_INSTANTIATED state,\nthat another lifecycle management operation is\nongoing, or that a required (see note) child attribute of\nthe \"extensions\" attribute has not been set.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\nnote: Required attributes are marked as \"required\" in the VNFD.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"VnfInstanceChangeExtConn.Post.202":{"description":"202 ACCEPTED\nThe request has been accepted for processing, but the processing has not been completed. The response body\nshall be empty. The HTTP response shall include a \"Location\" HTTP header that contains the URI of the\nnewly-created \"VNF LCM operation occurrence\" resource corresponding to the operation.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"Used in redirection, or when a new resource has been created. This header field shall be present if the\nresponse status code is 201 or 3xx. In the present document this header field is also used if the response\nstatus code is 202 and a new resource was created.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{}},"VnfInstanceChangeExtConn.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that another\nlifecycle management operation is ongoing, or that\na required (see note) child attribute of the\n\"extensions\" attribute has not been set.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\nnote: Required attributes are marked as \"required\" in the VNFD.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"VnfInstanceChangeVnfPkg.Post.202":{"description":"202 ACCEPTED\nShall be returned when the request has been accepted for processing.\nThe response body shall be empty. The HTTP response shall include a \"Location\" HTTP header that contains the URI\nof the newly-created \"Individual VNF LCM operation occurrence\" resource corresponding to the instantiation operation.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"Used in redirection, or when a new resource has been created. This header field shall be present if the\nresponse status code is 201 or 3xx. In the present document this header field is also used if the response\nstatus code is 202 and a new resource was created.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{}},"VnfInstanceChangeVnfPkg.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error:\nThe operation cannot be executed\ncurrently, due to a conflict with the state of\nthe resource.\nTypically, this is due to the fact that another\nlifecycle management operation is ongoing.\nThe response body shall contain a\nProblemDetails structure, in which the\n\"detail\" attribute shall convey more\ninformation about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"VnfLcmOpOccs.Get.200":{"description":"200 OK\nStatus information for zero or more VNF lifecycle management operation occurrences has been queried\nsuccessfully. The response body shall contain in an array the status information about zero or more VNF\nlifecycle operation occurrences, as defined in clause 5.5.2.13. If the VNFM supports alternative 2 (paging)\naccording to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource, inclusion of the Link HTTP header in\nthis response shall follow the provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"Version":{"description":"The used API version.\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a VNF lifecycle management operation occurrence. Shall be set to the value of the \"id\" attribute in the \"Grant\" representing the associated \"Individual Grant\", if such grant exists. * NOTE 1:\tThis allows the API consumer to obtain the information contained in the latest \"result\"\n notification if it has not received it due to an error or a wrongly configured subscription filter.\n* NOTE 2:\tNot more than one of changedInfo and modificationsTriggeredByVnfPkgChange shall be present. * NOTE 3:\tFor a particular affected VL, there shall be as many \"AffectedVirtualLink\" entries as needed\n for signalling the different types of changes, i.e. one per virtual link and change type.\n For instance, in the case of signaling affected VL instances involving the addition of a\n particular VL instance with links ports, one \"AffectedVirtualLink\" entry signals the addition\n of the VL by using the \"changeType\" attribute of \"AffectedVirtualLink\" structure equal to \"ADDED\",\n and another \"AffectedVirtualLink\" entry signals the addition of VNF link ports of the VL by using the\n \"changeType\" equal to \"LINK_PORT_ADDED\".\n* NOTE 4:\tA coordination action has timed out if the VNFM has not been able to read the\n \"Individual coordination action\" resource within a timeout interval after requesting the coordination\n to be started or to be cancelled. The length of the timeout interval is defined by means outside\n the scope of the present document.\n* NOTE 5: The list of rejected coordinations may be garbage collected if the LCM operation occurrence has\n reached a terminal state, i.e. one of \"COMPLETED\", \"FAILED\" and \"ROLLED_BACK\".\n","type":"object","oneOf":[{"required":["changedInfo"]},{"required":["modificationsTriggeredByVnfPkgChange"]}],"required":["id","operationState","stateEnteredTime","startTime","vnfInstanceId","operation","isAutomaticInvocation","isCancelPending"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"operationState":{"description":"STARTING: The LCM operation is starting. PROCESSING: The LCM operation is currently in execution. COMPLETED: The LCM operation has been completed successfully. FAILED_TEMP: The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED: The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK: The LCM operation is currently being rolled back. ROLLED_BACK: The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible.\n","type":"string","enum":["STARTING","PROCESSING","COMPLETED","FAILED_TEMP","FAILED","ROLLING_BACK","ROLLED_BACK"]},"stateEnteredTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"startTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"grantId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"operation":{"description":"The enumeration LcmOpType defines the permitted values to represent VNF lifecycle operation types in VNF lifecycle management operation occurrence resources and VNF lifecycle management operation occurrence notifications.\nValue | Description ------|------------ INSTANTIATE | Represents the \"Instantiate VNF\" LCM operation. SCALE | Represents the \"Scale VNF\" LCM operation. SCALE_TO_LEVEL | Represents the \"Scale VNF to Level\" LCM operation. CHANGE_FLAVOUR | Represents the \"Change VNF Flavour\" LCM operation. TERMINATE | Represents the \"Terminate VNF\" LCM operation. HEAL | Represents the \"Heal VNF\" LCM operation. OPERATE | Represents the \"Operate VNF\" LCM operation. CHANGE_EXT_CONN | Represents the \"Change external VNF connectivity\" LCM operation. MODIFY_INFO | Represents the \"Modify VNF Information\" LCM operation. CREATE_SNAPSHOT | Represents the \"Create VNF Snapshot\" LCM operation. REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot\" LCM operation. CHANGE_VNFPKG | Represents the \"Change current VNF package\" LCM operation. SELECT_DEPL_MODS | Represents the \"Select VNF deployable modules\" LCM operation\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","MODIFY_INFO","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","CHANGE_VNFPKG","SELECT_DEPL_MODS"]},"isAutomaticInvocation":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"operationParams":{"description":"Input parameters of the LCM operation. This attribute shall be formatted according to the request data type of the related LCM operation. In addition, the provisions in clause 5.7 shall apply. The following mapping between operationType and the data type of this attribute shall apply: * INSTANTIATE: InstantiateVnfRequest * SCALE: ScaleVnfRequest * SCALE_TO_LEVEL: ScaleVnfToLevelRequest * CHANGE_FLAVOUR: ChangeVnfFlavourRequest * OPERATE: OperateVnfRequest * HEAL: HealVnfRequest * CHANGE_EXT_CONN: ChangeExtVnfConnectivityRequest * TERMINATE: TerminateVnfRequest * MODIFY_INFO: VnfInfoModificationRequest * CREATE_SNAPSHOT: CreateVnfSnapshotRequest * REVERT_TO_SNAPSHOT: RevertToVnfSnapshotRequest * CHANGE_VNFPKG: ChangeCurrentVnfPkgRequest * SELECT_DEPL_MODS: SelectVnfDeployableModulesRequest\n","type":"object"},"isCancelPending":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"cancelMode":{"description":"Cancellation mode. GRACEFUL: If the VNF LCM operation occurrence is in \"PROCESSING\" or \"ROLLING_BACK\" state, the VNFM shall not start any new resource management operation and shall wait for the ongoing resource management operations in the underlying system, typically the VIM, to finish execution or to time out. After that, the VNFM shall put the operation occurrence into the FAILED_TEMP state. If the VNF LCM operation occurrence is in \"STARTING\" state, the VNFM shall not start any resource management operation and shall wait for the granting request to finish execution or time out. After that, the VNFM shall put the operation occurrence into the ROLLED_BACK state. FORCEFUL: If the VNF LCM operation occurrence is in \"PROCESSING\" or \"ROLLING_BACK\" state, the VNFM shall not start any new resource management operation, shall cancel the ongoing resource management operations in the underlying system, typically the VIM, and shall wait for the cancellation to finish or to time out. After that, the VNFM shall put the operation occurrence into the FAILED_TEMP state. If the VNF LCM operation occurrence is in \"STARTING\" state, the VNFM shall not start any resource management operation and put the operation occurrence into the ROLLED_BACK state.\n","type":"string","enum":["GRACEFUL","FORCEFUL"]},"error":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}},"resourceChanges":{"description":"This attribute contains information about the cumulative changes to virtualised resources that were performed so far by the LCM operation since its start, if applicable.\n","type":"object","properties":{"affectedVnfcs":{"description":"Information about VNFC instances that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary VNFCs.\n","type":"object","required":["id","vduId","changeType","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY For a temporary resource, an AffectedVnfc structure exists as long as the temporary resource exists.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY"]},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"affectedVnfcCpIds":{"description":"Identifiers of CP(s) of the VNFC instance that were affected by the change. Shall be present for those affected CPs of the VNFC instance that are associated to an external CP of the VNF instance. May be present for further affected CPs of the VNFC instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"addedStorageResourceIds":{"description":"References to VirtualStorage resources that have been added. Each value refers to a VirtualStorageResourceInfo item in the VnfInstance that was added to the VNFC. It shall be provided if at least one storage resource was added to the VNFC.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"removedStorageResourceIds":{"description":"References to VirtualStorage resources that have been removed. The value contains the identifier of a VirtualStorageResourceInfo item that has been removed from the VNFC, and might no longer exist in the VnfInstance. It shall be provided if at least one storage resource was removed from the VNFC.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"affectedVirtualLinks":{"description":"Information about VL instances that were affected during the lifecycle operation. See note 1 and note 3.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary VLs, and added or removed VNF link ports.\nNOTE:\tWhen signalling the addition (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) of VNF link ports, \n the \"networkResource\" attribute refers to the affected virtual link instance, not the link port \n instance. The resource handles of the affected VNF link ports can be found by dereferencing the \n identifiers in the \"vnfLinkPortIds\" attribute.\n","type":"object","required":["id","vnfVirtualLinkDescId","changeType","networkResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY * LINK_PORT_ADDED * LINK_PORT_REMOVED For a temporary resource, an AffectedVirtualLink structure exists as long as the temporary resource exists. When signalling the addition (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) of VNF link ports, the \"networkResource\" attribute refers to the affected virtual link instance, not the link port instance. The resource handles of the affected VNF link ports can be found by dereferencing the identifiers in the \"vnfLinkPortIds\" attribute.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY","LINK_PORT_ADDED","LINK_PORT_REMOVED"]},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPortIds":{"description":"Identifiers of the link ports of the affected VL related to the change. Each identifier references a \"VnfLinkPortInfo\" structure.\nShall be set when changeType is equal to \"LINK_PORT_ADDED\" or \"LINK_PORT_REMOVED\", and the related \"VnfLinkPortInfo\" structures are present (case \"added\") or have been present (case \"removed\") in the \"VnfVirtualLinkResourceInfo\" or \"ExtManagedVirtualLinkInfo\" structures that are represented by the \"vnfVirtualLinkResourceInfo\" or \"extManagedVirtualLinkInfo\" attribute in the \"VnfInstance\" structure. See note.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"affectedExtLinkPorts":{"description":"Information about external VNF link ports that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added and deleted external link ports (link ports attached to external virtual links).\n","type":"object","required":["id","changeType","extCpInstanceId","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: -\tADDED - MODIFIED -\tREMOVED\n","type":"string","enum":["ADDED","MODIFIED","REMOVED"]},"extCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"affectedVirtualStorages":{"description":"Information about virtualised storage instances that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary virtual storage resources.\n","type":"object","required":["id","virtualStorageDescId","changeType","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY For a temporary resource, an AffectedVirtualStorage structure exists as long as the temporary resource exists.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY"]},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"changedInfo":{"description":"This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource. The attributes that can be included consist of those requested to be modified explicitly in the \"VnfInfoModificationRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly e.g. when modifying the referenced VNF package. * NOTE:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute)\n was modified implicitly following a request to modify the \"vnfdId\" attribute, by\n copying the value of this attribute from the VNFD in the VNF Package identified\n by the \"vnfdId\" attribute.\n","type":"object","properties":{"vnfInstanceName":{"description":"If present, this attribute signals modifications of the \"vnfInstanceName\" attribute in \"VnfInstance\" as defined in clause 5.5.2.12..\n","type":"string"},"vnfInstanceDescription":{"description":"If present, this attribute signals modifications of the \"vnfInstanceDescription\" attribute in \"VnfInstance\", as defined in clause 5.5.2.12..\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"If present, this attribute signals modifications of the \"vnfProvider\" attribute in \"VnfInstance\". See note.\n","type":"string"},"vnfProductName":{"description":"If present, this attribute signals modifications of the \"vnfProductName\" attribute in \"VnfInstance\". See note.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vnfcInfoModifications":{"description":"If present, this attribute signals modifications of certain entries in the \"vnfcInfo\" attribute array in the \"instantiatedVnfInfo\" attribute of \"VnfInstance\", as defined in clause 5.5.2.12.\n","type":"array","items":{"description":"This type represents modifications of an entry in an array of \"VnfcInfo\" objects. * NOTE:\tThe attribute \"id\" in this data type represents the same identifier as the attribute\n \"vnfcInstanceId\" in other related data types in the present document. For reasons of backward\n compatibility, this misalignment is not corrected.\n","type":"object","required":["id","vnfcConfigurableProperties"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"affectedVipCps":{"description":"Information about virtual IP CP instances that were affected during the execution of the lifecycle management operation.\n","type":"array","items":{"description":"This type provides information about added, deleted and modified virtual IP CP instances.\n","type":"object","required":["cpInstanceId","cpdId","changeType"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: -\tADDED -\tREMOVED -\tMODIFIED\n","type":"string","enum":["ADDED","REMOVED","MODIFIED"]}}}},"changedExtConnectivity":{"description":"Information about changed external connectivity, if applicable. See note 1.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD. The key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO. The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5 and 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored.\n\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for \n Kubernetes® that supports configuration of address pools for load balancer services.\n\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"string"},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"string"}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"routingResource":{"description":"Network resources that provide the forwarding/routing capabilities associated to the network resource realizing this VL.\n","type":"array","items":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}}},"modificationsTriggeredByVnfPkgChange":{"description":"This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource when changing the current VNF package. The attributes that can be included consist of those requested to be modified explicitly in the \"ChangeCurrentVnfPkgRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly during the operation.\nNOTE 1:\tThis attribute represents the delta (semantics as per IETF RFC 7396, JSON Merge Patch) between the value \n of the attribute at the start of the \"Change current VNF package\" operation and the value of the attribute \n at its completion.\nNOTE 2:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) was modified implicitly \n during the related operation and contains a copy of the value of the related attribute from the VNFD in the \n VNF Package identified by the \"vnfdId\" attribute.\n","type":"object","properties":{"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"If present, this attribute signals the new value of the \"vnfProvider\" attribute in \"VnfInstance\". See note 2.\n","type":"string"},"vnfProductName":{"description":"If present, this attribute signals the new value of the \"vnfProductName\" attribute in \"VnfInstance\". See note 2.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"}}},"vnfSnapshotInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"lcmCoordinations":{"description":"Information about LCM coordination actions (see clause 10) related to this LCM operation occurrence.\n","type":"object","required":["id","coordinationActionName","startTime","endpointType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"coordinationActionName":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"coordinationResult":{"description":"The enumeration LcmCoordResultType defines the permitted values to represent the result of executing an LCM coordination action. The coordination result also implies the action to be performed by the VNFM as the follow-up to this coordination. Value | Description ------|------------ CONTINUE | The related LCM operation shall be continued, staying in the state \"PROCESSING\". ABORT | The related LCM operation shall be aborted by transitioning into the state \"FAILED_TEMP\". CANCELLED | The coordination action has been cancelled upon request of the API consumer, i.e. the VNFM. The related LCM operation shall be aborted by transitioning into the state \"FAILED_TEMP\".\n","type":"string","enum":["CONTINUE","ABORT","CANCELLED"]},"startTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"endTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"endpointType":{"description":"The endpoint type used by this coordination action. Valid values: - MGMT: coordination with other operation supporting management systems (e.g. EM) - VNF: coordination with the VNF instance\n","type":"string","enum":["MGMT","VNF"]},"delay":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}},"rejectedLcmCoordinations":{"description":"Information about LCM coordination actions (see clause 10) that were rejected by 503 error which means they will be tried again after a delay. See note 5.\n","type":"object","required":["coordinationActionName","rejectionTime","endpointType","delay"],"properties":{"coordinationActionName":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"rejectionTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"endpointType":{"description":"The endpoint type used by this coordination action. Valid values: - MGMT: coordination with other operation supporting management systems (e.g. EM) - VNF: coordination with the VNF instance\n","type":"string","enum":["MGMT","VNF"]},"delay":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}},"warnings":{"description":"Warning messages that were generated while the operation was executing.\nIf the operation has included LCM coordination actions and these have resulted in warnings, such warnings should be added to this attribute.\n","type":"array","items":{"type":"string"}},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self","vnfInstance"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"grant":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"cancel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"retry":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"rollback":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"fail":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"IndividualVnfLcmOpOcc.Get.200":{"description":"200 OK\nInformation about an individual VNF instance has been queried successfully. The response body shall contain\nstatus information about a VNF lifecycle management operation occurrence.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a VNF lifecycle management operation occurrence. Shall be set to the value of the \"id\" attribute in the \"Grant\" representing the associated \"Individual Grant\", if such grant exists. * NOTE 1:\tThis allows the API consumer to obtain the information contained in the latest \"result\"\n notification if it has not received it due to an error or a wrongly configured subscription filter.\n* NOTE 2:\tNot more than one of changedInfo and modificationsTriggeredByVnfPkgChange shall be present. * NOTE 3:\tFor a particular affected VL, there shall be as many \"AffectedVirtualLink\" entries as needed\n for signalling the different types of changes, i.e. one per virtual link and change type.\n For instance, in the case of signaling affected VL instances involving the addition of a\n particular VL instance with links ports, one \"AffectedVirtualLink\" entry signals the addition\n of the VL by using the \"changeType\" attribute of \"AffectedVirtualLink\" structure equal to \"ADDED\",\n and another \"AffectedVirtualLink\" entry signals the addition of VNF link ports of the VL by using the\n \"changeType\" equal to \"LINK_PORT_ADDED\".\n* NOTE 4:\tA coordination action has timed out if the VNFM has not been able to read the\n \"Individual coordination action\" resource within a timeout interval after requesting the coordination\n to be started or to be cancelled. The length of the timeout interval is defined by means outside\n the scope of the present document.\n* NOTE 5: The list of rejected coordinations may be garbage collected if the LCM operation occurrence has\n reached a terminal state, i.e. one of \"COMPLETED\", \"FAILED\" and \"ROLLED_BACK\".\n","type":"object","oneOf":[{"required":["changedInfo"]},{"required":["modificationsTriggeredByVnfPkgChange"]}],"required":["id","operationState","stateEnteredTime","startTime","vnfInstanceId","operation","isAutomaticInvocation","isCancelPending"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"operationState":{"description":"STARTING: The LCM operation is starting. PROCESSING: The LCM operation is currently in execution. COMPLETED: The LCM operation has been completed successfully. FAILED_TEMP: The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED: The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK: The LCM operation is currently being rolled back. ROLLED_BACK: The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible.\n","type":"string","enum":["STARTING","PROCESSING","COMPLETED","FAILED_TEMP","FAILED","ROLLING_BACK","ROLLED_BACK"]},"stateEnteredTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"startTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"grantId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"operation":{"description":"The enumeration LcmOpType defines the permitted values to represent VNF lifecycle operation types in VNF lifecycle management operation occurrence resources and VNF lifecycle management operation occurrence notifications.\nValue | Description ------|------------ INSTANTIATE | Represents the \"Instantiate VNF\" LCM operation. SCALE | Represents the \"Scale VNF\" LCM operation. SCALE_TO_LEVEL | Represents the \"Scale VNF to Level\" LCM operation. CHANGE_FLAVOUR | Represents the \"Change VNF Flavour\" LCM operation. TERMINATE | Represents the \"Terminate VNF\" LCM operation. HEAL | Represents the \"Heal VNF\" LCM operation. OPERATE | Represents the \"Operate VNF\" LCM operation. CHANGE_EXT_CONN | Represents the \"Change external VNF connectivity\" LCM operation. MODIFY_INFO | Represents the \"Modify VNF Information\" LCM operation. CREATE_SNAPSHOT | Represents the \"Create VNF Snapshot\" LCM operation. REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot\" LCM operation. CHANGE_VNFPKG | Represents the \"Change current VNF package\" LCM operation. SELECT_DEPL_MODS | Represents the \"Select VNF deployable modules\" LCM operation\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","MODIFY_INFO","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","CHANGE_VNFPKG","SELECT_DEPL_MODS"]},"isAutomaticInvocation":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"operationParams":{"description":"Input parameters of the LCM operation. This attribute shall be formatted according to the request data type of the related LCM operation. In addition, the provisions in clause 5.7 shall apply. The following mapping between operationType and the data type of this attribute shall apply: * INSTANTIATE: InstantiateVnfRequest * SCALE: ScaleVnfRequest * SCALE_TO_LEVEL: ScaleVnfToLevelRequest * CHANGE_FLAVOUR: ChangeVnfFlavourRequest * OPERATE: OperateVnfRequest * HEAL: HealVnfRequest * CHANGE_EXT_CONN: ChangeExtVnfConnectivityRequest * TERMINATE: TerminateVnfRequest * MODIFY_INFO: VnfInfoModificationRequest * CREATE_SNAPSHOT: CreateVnfSnapshotRequest * REVERT_TO_SNAPSHOT: RevertToVnfSnapshotRequest * CHANGE_VNFPKG: ChangeCurrentVnfPkgRequest * SELECT_DEPL_MODS: SelectVnfDeployableModulesRequest\n","type":"object"},"isCancelPending":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"cancelMode":{"description":"Cancellation mode. GRACEFUL: If the VNF LCM operation occurrence is in \"PROCESSING\" or \"ROLLING_BACK\" state, the VNFM shall not start any new resource management operation and shall wait for the ongoing resource management operations in the underlying system, typically the VIM, to finish execution or to time out. After that, the VNFM shall put the operation occurrence into the FAILED_TEMP state. If the VNF LCM operation occurrence is in \"STARTING\" state, the VNFM shall not start any resource management operation and shall wait for the granting request to finish execution or time out. After that, the VNFM shall put the operation occurrence into the ROLLED_BACK state. FORCEFUL: If the VNF LCM operation occurrence is in \"PROCESSING\" or \"ROLLING_BACK\" state, the VNFM shall not start any new resource management operation, shall cancel the ongoing resource management operations in the underlying system, typically the VIM, and shall wait for the cancellation to finish or to time out. After that, the VNFM shall put the operation occurrence into the FAILED_TEMP state. If the VNF LCM operation occurrence is in \"STARTING\" state, the VNFM shall not start any resource management operation and put the operation occurrence into the ROLLED_BACK state.\n","type":"string","enum":["GRACEFUL","FORCEFUL"]},"error":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}},"resourceChanges":{"description":"This attribute contains information about the cumulative changes to virtualised resources that were performed so far by the LCM operation since its start, if applicable.\n","type":"object","properties":{"affectedVnfcs":{"description":"Information about VNFC instances that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary VNFCs.\n","type":"object","required":["id","vduId","changeType","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY For a temporary resource, an AffectedVnfc structure exists as long as the temporary resource exists.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY"]},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"affectedVnfcCpIds":{"description":"Identifiers of CP(s) of the VNFC instance that were affected by the change. Shall be present for those affected CPs of the VNFC instance that are associated to an external CP of the VNF instance. May be present for further affected CPs of the VNFC instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"addedStorageResourceIds":{"description":"References to VirtualStorage resources that have been added. Each value refers to a VirtualStorageResourceInfo item in the VnfInstance that was added to the VNFC. It shall be provided if at least one storage resource was added to the VNFC.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"removedStorageResourceIds":{"description":"References to VirtualStorage resources that have been removed. The value contains the identifier of a VirtualStorageResourceInfo item that has been removed from the VNFC, and might no longer exist in the VnfInstance. It shall be provided if at least one storage resource was removed from the VNFC.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"affectedVirtualLinks":{"description":"Information about VL instances that were affected during the lifecycle operation. See note 1 and note 3.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary VLs, and added or removed VNF link ports.\nNOTE:\tWhen signalling the addition (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) of VNF link ports, \n the \"networkResource\" attribute refers to the affected virtual link instance, not the link port \n instance. The resource handles of the affected VNF link ports can be found by dereferencing the \n identifiers in the \"vnfLinkPortIds\" attribute.\n","type":"object","required":["id","vnfVirtualLinkDescId","changeType","networkResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY * LINK_PORT_ADDED * LINK_PORT_REMOVED For a temporary resource, an AffectedVirtualLink structure exists as long as the temporary resource exists. When signalling the addition (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) of VNF link ports, the \"networkResource\" attribute refers to the affected virtual link instance, not the link port instance. The resource handles of the affected VNF link ports can be found by dereferencing the identifiers in the \"vnfLinkPortIds\" attribute.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY","LINK_PORT_ADDED","LINK_PORT_REMOVED"]},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPortIds":{"description":"Identifiers of the link ports of the affected VL related to the change. Each identifier references a \"VnfLinkPortInfo\" structure.\nShall be set when changeType is equal to \"LINK_PORT_ADDED\" or \"LINK_PORT_REMOVED\", and the related \"VnfLinkPortInfo\" structures are present (case \"added\") or have been present (case \"removed\") in the \"VnfVirtualLinkResourceInfo\" or \"ExtManagedVirtualLinkInfo\" structures that are represented by the \"vnfVirtualLinkResourceInfo\" or \"extManagedVirtualLinkInfo\" attribute in the \"VnfInstance\" structure. See note.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"affectedExtLinkPorts":{"description":"Information about external VNF link ports that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added and deleted external link ports (link ports attached to external virtual links).\n","type":"object","required":["id","changeType","extCpInstanceId","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: -\tADDED - MODIFIED -\tREMOVED\n","type":"string","enum":["ADDED","MODIFIED","REMOVED"]},"extCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"affectedVirtualStorages":{"description":"Information about virtualised storage instances that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary virtual storage resources.\n","type":"object","required":["id","virtualStorageDescId","changeType","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY For a temporary resource, an AffectedVirtualStorage structure exists as long as the temporary resource exists.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY"]},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"changedInfo":{"description":"This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource. The attributes that can be included consist of those requested to be modified explicitly in the \"VnfInfoModificationRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly e.g. when modifying the referenced VNF package. * NOTE:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute)\n was modified implicitly following a request to modify the \"vnfdId\" attribute, by\n copying the value of this attribute from the VNFD in the VNF Package identified\n by the \"vnfdId\" attribute.\n","type":"object","properties":{"vnfInstanceName":{"description":"If present, this attribute signals modifications of the \"vnfInstanceName\" attribute in \"VnfInstance\" as defined in clause 5.5.2.12..\n","type":"string"},"vnfInstanceDescription":{"description":"If present, this attribute signals modifications of the \"vnfInstanceDescription\" attribute in \"VnfInstance\", as defined in clause 5.5.2.12..\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"If present, this attribute signals modifications of the \"vnfProvider\" attribute in \"VnfInstance\". See note.\n","type":"string"},"vnfProductName":{"description":"If present, this attribute signals modifications of the \"vnfProductName\" attribute in \"VnfInstance\". See note.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vnfcInfoModifications":{"description":"If present, this attribute signals modifications of certain entries in the \"vnfcInfo\" attribute array in the \"instantiatedVnfInfo\" attribute of \"VnfInstance\", as defined in clause 5.5.2.12.\n","type":"array","items":{"description":"This type represents modifications of an entry in an array of \"VnfcInfo\" objects. * NOTE:\tThe attribute \"id\" in this data type represents the same identifier as the attribute\n \"vnfcInstanceId\" in other related data types in the present document. For reasons of backward\n compatibility, this misalignment is not corrected.\n","type":"object","required":["id","vnfcConfigurableProperties"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"affectedVipCps":{"description":"Information about virtual IP CP instances that were affected during the execution of the lifecycle management operation.\n","type":"array","items":{"description":"This type provides information about added, deleted and modified virtual IP CP instances.\n","type":"object","required":["cpInstanceId","cpdId","changeType"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: -\tADDED -\tREMOVED -\tMODIFIED\n","type":"string","enum":["ADDED","REMOVED","MODIFIED"]}}}},"changedExtConnectivity":{"description":"Information about changed external connectivity, if applicable. See note 1.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD. The key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO. The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5 and 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored.\n\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for \n Kubernetes® that supports configuration of address pools for load balancer services.\n\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"string"},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"string"}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"routingResource":{"description":"Network resources that provide the forwarding/routing capabilities associated to the network resource realizing this VL.\n","type":"array","items":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}}},"modificationsTriggeredByVnfPkgChange":{"description":"This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource when changing the current VNF package. The attributes that can be included consist of those requested to be modified explicitly in the \"ChangeCurrentVnfPkgRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly during the operation.\nNOTE 1:\tThis attribute represents the delta (semantics as per IETF RFC 7396, JSON Merge Patch) between the value \n of the attribute at the start of the \"Change current VNF package\" operation and the value of the attribute \n at its completion.\nNOTE 2:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) was modified implicitly \n during the related operation and contains a copy of the value of the related attribute from the VNFD in the \n VNF Package identified by the \"vnfdId\" attribute.\n","type":"object","properties":{"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"If present, this attribute signals the new value of the \"vnfProvider\" attribute in \"VnfInstance\". See note 2.\n","type":"string"},"vnfProductName":{"description":"If present, this attribute signals the new value of the \"vnfProductName\" attribute in \"VnfInstance\". See note 2.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"}}},"vnfSnapshotInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"lcmCoordinations":{"description":"Information about LCM coordination actions (see clause 10) related to this LCM operation occurrence.\n","type":"object","required":["id","coordinationActionName","startTime","endpointType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"coordinationActionName":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"coordinationResult":{"description":"The enumeration LcmCoordResultType defines the permitted values to represent the result of executing an LCM coordination action. The coordination result also implies the action to be performed by the VNFM as the follow-up to this coordination. Value | Description ------|------------ CONTINUE | The related LCM operation shall be continued, staying in the state \"PROCESSING\". ABORT | The related LCM operation shall be aborted by transitioning into the state \"FAILED_TEMP\". CANCELLED | The coordination action has been cancelled upon request of the API consumer, i.e. the VNFM. The related LCM operation shall be aborted by transitioning into the state \"FAILED_TEMP\".\n","type":"string","enum":["CONTINUE","ABORT","CANCELLED"]},"startTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"endTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"endpointType":{"description":"The endpoint type used by this coordination action. Valid values: - MGMT: coordination with other operation supporting management systems (e.g. EM) - VNF: coordination with the VNF instance\n","type":"string","enum":["MGMT","VNF"]},"delay":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}},"rejectedLcmCoordinations":{"description":"Information about LCM coordination actions (see clause 10) that were rejected by 503 error which means they will be tried again after a delay. See note 5.\n","type":"object","required":["coordinationActionName","rejectionTime","endpointType","delay"],"properties":{"coordinationActionName":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"rejectionTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"endpointType":{"description":"The endpoint type used by this coordination action. Valid values: - MGMT: coordination with other operation supporting management systems (e.g. EM) - VNF: coordination with the VNF instance\n","type":"string","enum":["MGMT","VNF"]},"delay":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}},"warnings":{"description":"Warning messages that were generated while the operation was executing.\nIf the operation has included LCM coordination actions and these have resulted in warnings, such warnings should be added to this attribute.\n","type":"array","items":{"type":"string"}},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self","vnfInstance"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"grant":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"cancel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"retry":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"rollback":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"fail":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"VnfLcmOpOccRetry.Post.202":{"description":"202 ACCEPTED\nThe request has been accepted for processing, but processing has not been completed. The response shall\nhave an empty message content.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{}},"VnfLcmOpOccRetry.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the VNF LCM operation\noccurrence.\nTypically, this is due to the fact that the VNF LCM\noperation occurrence is not in FAILED_TEMP state\nor another error handling action is starting such as\nrollback or fail.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"VnfLcmOpOccRollback.Post.202":{"description":"202 ACCEPTED\nThe request has been accepted for processing, but processing has not been completed. The response shall have\nan empty message content.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{}},"VnfLcmOpOccRollback.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the VNF LCM operation\noccurrence.\nTypically, this is due to the fact that the VNF LCM\noperation occurrence is not in FAILED_TEMP state\nor another error handling action is starting such as\nretry or fail.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"VnfLcmOpOccFail.Post.200":{"description":"200 OK\nThe state of the VNF lifecycle management operation occurrence has been changed successfully. The response\nshall include a representation of the \"Individual VNF lifecycle operation occurrence\" resource.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a VNF lifecycle management operation occurrence. Shall be set to the value of the \"id\" attribute in the \"Grant\" representing the associated \"Individual Grant\", if such grant exists. * NOTE 1:\tThis allows the API consumer to obtain the information contained in the latest \"result\"\n notification if it has not received it due to an error or a wrongly configured subscription filter.\n* NOTE 2:\tNot more than one of changedInfo and modificationsTriggeredByVnfPkgChange shall be present. * NOTE 3:\tFor a particular affected VL, there shall be as many \"AffectedVirtualLink\" entries as needed\n for signalling the different types of changes, i.e. one per virtual link and change type.\n For instance, in the case of signaling affected VL instances involving the addition of a\n particular VL instance with links ports, one \"AffectedVirtualLink\" entry signals the addition\n of the VL by using the \"changeType\" attribute of \"AffectedVirtualLink\" structure equal to \"ADDED\",\n and another \"AffectedVirtualLink\" entry signals the addition of VNF link ports of the VL by using the\n \"changeType\" equal to \"LINK_PORT_ADDED\".\n* NOTE 4:\tA coordination action has timed out if the VNFM has not been able to read the\n \"Individual coordination action\" resource within a timeout interval after requesting the coordination\n to be started or to be cancelled. The length of the timeout interval is defined by means outside\n the scope of the present document.\n* NOTE 5: The list of rejected coordinations may be garbage collected if the LCM operation occurrence has\n reached a terminal state, i.e. one of \"COMPLETED\", \"FAILED\" and \"ROLLED_BACK\".\n","type":"object","oneOf":[{"required":["changedInfo"]},{"required":["modificationsTriggeredByVnfPkgChange"]}],"required":["id","operationState","stateEnteredTime","startTime","vnfInstanceId","operation","isAutomaticInvocation","isCancelPending"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"operationState":{"description":"STARTING: The LCM operation is starting. PROCESSING: The LCM operation is currently in execution. COMPLETED: The LCM operation has been completed successfully. FAILED_TEMP: The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED: The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK: The LCM operation is currently being rolled back. ROLLED_BACK: The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible.\n","type":"string","enum":["STARTING","PROCESSING","COMPLETED","FAILED_TEMP","FAILED","ROLLING_BACK","ROLLED_BACK"]},"stateEnteredTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"startTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"grantId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"operation":{"description":"The enumeration LcmOpType defines the permitted values to represent VNF lifecycle operation types in VNF lifecycle management operation occurrence resources and VNF lifecycle management operation occurrence notifications.\nValue | Description ------|------------ INSTANTIATE | Represents the \"Instantiate VNF\" LCM operation. SCALE | Represents the \"Scale VNF\" LCM operation. SCALE_TO_LEVEL | Represents the \"Scale VNF to Level\" LCM operation. CHANGE_FLAVOUR | Represents the \"Change VNF Flavour\" LCM operation. TERMINATE | Represents the \"Terminate VNF\" LCM operation. HEAL | Represents the \"Heal VNF\" LCM operation. OPERATE | Represents the \"Operate VNF\" LCM operation. CHANGE_EXT_CONN | Represents the \"Change external VNF connectivity\" LCM operation. MODIFY_INFO | Represents the \"Modify VNF Information\" LCM operation. CREATE_SNAPSHOT | Represents the \"Create VNF Snapshot\" LCM operation. REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot\" LCM operation. CHANGE_VNFPKG | Represents the \"Change current VNF package\" LCM operation. SELECT_DEPL_MODS | Represents the \"Select VNF deployable modules\" LCM operation\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","MODIFY_INFO","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","CHANGE_VNFPKG","SELECT_DEPL_MODS"]},"isAutomaticInvocation":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"operationParams":{"description":"Input parameters of the LCM operation. This attribute shall be formatted according to the request data type of the related LCM operation. In addition, the provisions in clause 5.7 shall apply. The following mapping between operationType and the data type of this attribute shall apply: * INSTANTIATE: InstantiateVnfRequest * SCALE: ScaleVnfRequest * SCALE_TO_LEVEL: ScaleVnfToLevelRequest * CHANGE_FLAVOUR: ChangeVnfFlavourRequest * OPERATE: OperateVnfRequest * HEAL: HealVnfRequest * CHANGE_EXT_CONN: ChangeExtVnfConnectivityRequest * TERMINATE: TerminateVnfRequest * MODIFY_INFO: VnfInfoModificationRequest * CREATE_SNAPSHOT: CreateVnfSnapshotRequest * REVERT_TO_SNAPSHOT: RevertToVnfSnapshotRequest * CHANGE_VNFPKG: ChangeCurrentVnfPkgRequest * SELECT_DEPL_MODS: SelectVnfDeployableModulesRequest\n","type":"object"},"isCancelPending":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"cancelMode":{"description":"Cancellation mode. GRACEFUL: If the VNF LCM operation occurrence is in \"PROCESSING\" or \"ROLLING_BACK\" state, the VNFM shall not start any new resource management operation and shall wait for the ongoing resource management operations in the underlying system, typically the VIM, to finish execution or to time out. After that, the VNFM shall put the operation occurrence into the FAILED_TEMP state. If the VNF LCM operation occurrence is in \"STARTING\" state, the VNFM shall not start any resource management operation and shall wait for the granting request to finish execution or time out. After that, the VNFM shall put the operation occurrence into the ROLLED_BACK state. FORCEFUL: If the VNF LCM operation occurrence is in \"PROCESSING\" or \"ROLLING_BACK\" state, the VNFM shall not start any new resource management operation, shall cancel the ongoing resource management operations in the underlying system, typically the VIM, and shall wait for the cancellation to finish or to time out. After that, the VNFM shall put the operation occurrence into the FAILED_TEMP state. If the VNF LCM operation occurrence is in \"STARTING\" state, the VNFM shall not start any resource management operation and put the operation occurrence into the ROLLED_BACK state.\n","type":"string","enum":["GRACEFUL","FORCEFUL"]},"error":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}},"resourceChanges":{"description":"This attribute contains information about the cumulative changes to virtualised resources that were performed so far by the LCM operation since its start, if applicable.\n","type":"object","properties":{"affectedVnfcs":{"description":"Information about VNFC instances that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary VNFCs.\n","type":"object","required":["id","vduId","changeType","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY For a temporary resource, an AffectedVnfc structure exists as long as the temporary resource exists.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY"]},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"affectedVnfcCpIds":{"description":"Identifiers of CP(s) of the VNFC instance that were affected by the change. Shall be present for those affected CPs of the VNFC instance that are associated to an external CP of the VNF instance. May be present for further affected CPs of the VNFC instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"addedStorageResourceIds":{"description":"References to VirtualStorage resources that have been added. Each value refers to a VirtualStorageResourceInfo item in the VnfInstance that was added to the VNFC. It shall be provided if at least one storage resource was added to the VNFC.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"removedStorageResourceIds":{"description":"References to VirtualStorage resources that have been removed. The value contains the identifier of a VirtualStorageResourceInfo item that has been removed from the VNFC, and might no longer exist in the VnfInstance. It shall be provided if at least one storage resource was removed from the VNFC.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"affectedVirtualLinks":{"description":"Information about VL instances that were affected during the lifecycle operation. See note 1 and note 3.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary VLs, and added or removed VNF link ports.\nNOTE:\tWhen signalling the addition (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) of VNF link ports, \n the \"networkResource\" attribute refers to the affected virtual link instance, not the link port \n instance. The resource handles of the affected VNF link ports can be found by dereferencing the \n identifiers in the \"vnfLinkPortIds\" attribute.\n","type":"object","required":["id","vnfVirtualLinkDescId","changeType","networkResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY * LINK_PORT_ADDED * LINK_PORT_REMOVED For a temporary resource, an AffectedVirtualLink structure exists as long as the temporary resource exists. When signalling the addition (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) of VNF link ports, the \"networkResource\" attribute refers to the affected virtual link instance, not the link port instance. The resource handles of the affected VNF link ports can be found by dereferencing the identifiers in the \"vnfLinkPortIds\" attribute.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY","LINK_PORT_ADDED","LINK_PORT_REMOVED"]},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPortIds":{"description":"Identifiers of the link ports of the affected VL related to the change. Each identifier references a \"VnfLinkPortInfo\" structure.\nShall be set when changeType is equal to \"LINK_PORT_ADDED\" or \"LINK_PORT_REMOVED\", and the related \"VnfLinkPortInfo\" structures are present (case \"added\") or have been present (case \"removed\") in the \"VnfVirtualLinkResourceInfo\" or \"ExtManagedVirtualLinkInfo\" structures that are represented by the \"vnfVirtualLinkResourceInfo\" or \"extManagedVirtualLinkInfo\" attribute in the \"VnfInstance\" structure. See note.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"affectedExtLinkPorts":{"description":"Information about external VNF link ports that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added and deleted external link ports (link ports attached to external virtual links).\n","type":"object","required":["id","changeType","extCpInstanceId","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: -\tADDED - MODIFIED -\tREMOVED\n","type":"string","enum":["ADDED","MODIFIED","REMOVED"]},"extCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"affectedVirtualStorages":{"description":"Information about virtualised storage instances that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary virtual storage resources.\n","type":"object","required":["id","virtualStorageDescId","changeType","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY For a temporary resource, an AffectedVirtualStorage structure exists as long as the temporary resource exists.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY"]},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"changedInfo":{"description":"This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource. The attributes that can be included consist of those requested to be modified explicitly in the \"VnfInfoModificationRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly e.g. when modifying the referenced VNF package. * NOTE:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute)\n was modified implicitly following a request to modify the \"vnfdId\" attribute, by\n copying the value of this attribute from the VNFD in the VNF Package identified\n by the \"vnfdId\" attribute.\n","type":"object","properties":{"vnfInstanceName":{"description":"If present, this attribute signals modifications of the \"vnfInstanceName\" attribute in \"VnfInstance\" as defined in clause 5.5.2.12..\n","type":"string"},"vnfInstanceDescription":{"description":"If present, this attribute signals modifications of the \"vnfInstanceDescription\" attribute in \"VnfInstance\", as defined in clause 5.5.2.12..\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"If present, this attribute signals modifications of the \"vnfProvider\" attribute in \"VnfInstance\". See note.\n","type":"string"},"vnfProductName":{"description":"If present, this attribute signals modifications of the \"vnfProductName\" attribute in \"VnfInstance\". See note.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vnfcInfoModifications":{"description":"If present, this attribute signals modifications of certain entries in the \"vnfcInfo\" attribute array in the \"instantiatedVnfInfo\" attribute of \"VnfInstance\", as defined in clause 5.5.2.12.\n","type":"array","items":{"description":"This type represents modifications of an entry in an array of \"VnfcInfo\" objects. * NOTE:\tThe attribute \"id\" in this data type represents the same identifier as the attribute\n \"vnfcInstanceId\" in other related data types in the present document. For reasons of backward\n compatibility, this misalignment is not corrected.\n","type":"object","required":["id","vnfcConfigurableProperties"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"affectedVipCps":{"description":"Information about virtual IP CP instances that were affected during the execution of the lifecycle management operation.\n","type":"array","items":{"description":"This type provides information about added, deleted and modified virtual IP CP instances.\n","type":"object","required":["cpInstanceId","cpdId","changeType"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: -\tADDED -\tREMOVED -\tMODIFIED\n","type":"string","enum":["ADDED","REMOVED","MODIFIED"]}}}},"changedExtConnectivity":{"description":"Information about changed external connectivity, if applicable. See note 1.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD. The key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO. The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5 and 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored.\n\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for \n Kubernetes® that supports configuration of address pools for load balancer services.\n\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"string"},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"string"}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"routingResource":{"description":"Network resources that provide the forwarding/routing capabilities associated to the network resource realizing this VL.\n","type":"array","items":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}}},"modificationsTriggeredByVnfPkgChange":{"description":"This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource when changing the current VNF package. The attributes that can be included consist of those requested to be modified explicitly in the \"ChangeCurrentVnfPkgRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly during the operation.\nNOTE 1:\tThis attribute represents the delta (semantics as per IETF RFC 7396, JSON Merge Patch) between the value \n of the attribute at the start of the \"Change current VNF package\" operation and the value of the attribute \n at its completion.\nNOTE 2:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) was modified implicitly \n during the related operation and contains a copy of the value of the related attribute from the VNFD in the \n VNF Package identified by the \"vnfdId\" attribute.\n","type":"object","properties":{"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"If present, this attribute signals the new value of the \"vnfProvider\" attribute in \"VnfInstance\". See note 2.\n","type":"string"},"vnfProductName":{"description":"If present, this attribute signals the new value of the \"vnfProductName\" attribute in \"VnfInstance\". See note 2.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"}}},"vnfSnapshotInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"lcmCoordinations":{"description":"Information about LCM coordination actions (see clause 10) related to this LCM operation occurrence.\n","type":"object","required":["id","coordinationActionName","startTime","endpointType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"coordinationActionName":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"coordinationResult":{"description":"The enumeration LcmCoordResultType defines the permitted values to represent the result of executing an LCM coordination action. The coordination result also implies the action to be performed by the VNFM as the follow-up to this coordination. Value | Description ------|------------ CONTINUE | The related LCM operation shall be continued, staying in the state \"PROCESSING\". ABORT | The related LCM operation shall be aborted by transitioning into the state \"FAILED_TEMP\". CANCELLED | The coordination action has been cancelled upon request of the API consumer, i.e. the VNFM. The related LCM operation shall be aborted by transitioning into the state \"FAILED_TEMP\".\n","type":"string","enum":["CONTINUE","ABORT","CANCELLED"]},"startTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"endTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"endpointType":{"description":"The endpoint type used by this coordination action. Valid values: - MGMT: coordination with other operation supporting management systems (e.g. EM) - VNF: coordination with the VNF instance\n","type":"string","enum":["MGMT","VNF"]},"delay":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}},"rejectedLcmCoordinations":{"description":"Information about LCM coordination actions (see clause 10) that were rejected by 503 error which means they will be tried again after a delay. See note 5.\n","type":"object","required":["coordinationActionName","rejectionTime","endpointType","delay"],"properties":{"coordinationActionName":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"rejectionTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"endpointType":{"description":"The endpoint type used by this coordination action. Valid values: - MGMT: coordination with other operation supporting management systems (e.g. EM) - VNF: coordination with the VNF instance\n","type":"string","enum":["MGMT","VNF"]},"delay":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}},"warnings":{"description":"Warning messages that were generated while the operation was executing.\nIf the operation has included LCM coordination actions and these have resulted in warnings, such warnings should be added to this attribute.\n","type":"array","items":{"type":"string"}},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self","vnfInstance"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"grant":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"cancel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"retry":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"rollback":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"fail":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"VnfLcmOpOccFail.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the VNF LCM operation\noccurrence.\nTypically, this is due to the fact that the VNF LCM\noperation occurrence is not in FAILED_TEMP state or\nanother error handling action is starting such as retry\nor rollback.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"VnfLcmOpOccCancel.Post.202":{"description":"202 ACCEPTED\nThe request has been accepted for processing, but processing has not been completed. The response shall\nhave an empty message content.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{}},"VnfLcmOpOccCancel.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the VNF LCM operation\noccurrence.\nTypically, this is due to the fact that the operation\noccurrence is not in STARTING, PROCESSING or\nROLLING_BACK state.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"Subscriptions.Get.200":{"description":"200 OK\nShall be returned when the list of subscriptions has been queried successfully.\nThe response body shall contain in an array the representations of all active subscriptions of\nthe functional block that invokes the method, i.e. zero or more representations of lifecycle change\nnotification subscriptions as defined in clause 5.5.2.16.\nIf the \"filter\" URI parameter was supplied in the request, the data in the response body shall have been\ntransformed according to the rules specified in clause 5.2.2 of ETSI GS NFV-SOL 013.\nIf the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013\nfor this resource, inclusion of the Link HTTP header in this response shall follow the provisions\nin clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a subscription related to notifications about VNF lifecycle changes.\n","type":"object","required":["id","callbackUri","verbosity","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications about VNF lifecycle changes.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of \n the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdIds"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tVnfLcmOperationOccurrenceNotification -\tVnfIdentifierCreationNotification -\tVnfIdentifierDeletionNotification See note.\n","type":"array","items":{"type":"string","enum":["VnfLcmOperationOccurrenceNotification","VnfIdentifierCreationNotification","VnfIdentifierDeletionNotification"]}},"operationTypes":{"description":"Match particular VNF lifecycle operation types for the notification of type VnfLcmOperationOccurrenceNotification. May be present if the \"notificationTypes\" attribute contains the value \"VnfLcmOperationOccurrenceNotification\", and shall be absent otherwise.\n","type":"array","items":{"description":"The enumeration LcmOpType defines the permitted values to represent VNF lifecycle operation types in VNF lifecycle management operation occurrence resources and VNF lifecycle management operation occurrence notifications.\nValue | Description ------|------------ INSTANTIATE | Represents the \"Instantiate VNF\" LCM operation. SCALE | Represents the \"Scale VNF\" LCM operation. SCALE_TO_LEVEL | Represents the \"Scale VNF to Level\" LCM operation. CHANGE_FLAVOUR | Represents the \"Change VNF Flavour\" LCM operation. TERMINATE | Represents the \"Terminate VNF\" LCM operation. HEAL | Represents the \"Heal VNF\" LCM operation. OPERATE | Represents the \"Operate VNF\" LCM operation. CHANGE_EXT_CONN | Represents the \"Change external VNF connectivity\" LCM operation. MODIFY_INFO | Represents the \"Modify VNF Information\" LCM operation. CREATE_SNAPSHOT | Represents the \"Create VNF Snapshot\" LCM operation. REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot\" LCM operation. CHANGE_VNFPKG | Represents the \"Change current VNF package\" LCM operation. SELECT_DEPL_MODS | Represents the \"Select VNF deployable modules\" LCM operation\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","MODIFY_INFO","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","CHANGE_VNFPKG","SELECT_DEPL_MODS"]}},"operationStates":{"description":"Match particular LCM operation state values as reported in notifications of type VnfLcmOperationOccurrenceNotification. May be present if the \"notificationTypes\" attribute contains the value \"VnfLcmOperationOccurrenceNotification\", and shall be absent otherwise.\n","type":"array","items":{"description":"STARTING: The LCM operation is starting. PROCESSING: The LCM operation is currently in execution. COMPLETED: The LCM operation has been completed successfully. FAILED_TEMP: The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED: The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK: The LCM operation is currently being rolled back. ROLLED_BACK: The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible.\n","type":"string","enum":["STARTING","PROCESSING","COMPLETED","FAILED_TEMP","FAILED","ROLLING_BACK","ROLLED_BACK"]}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"verbosity":{"description":"The enumeration LcmOpOccNotificationVerbosityType provides values to control the verbosity of LCM operation occurrence notifications. * FULL: This signals a full notification which contains all change details. * SHORT: This signals a short notification which omits large-volume change details to reduce the size of data to be sent via the notification mechanism.\n","type":"string","enum":["FULL","SHORT"]},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"Subscriptions.Post.201":{"description":"201 CREATED\nThe subscription has been created successfully. The response body shall contain a representation of the\ncreated \"Individual subscription\" resource. The HTTP response shall include a \"Location\" HTTP header that points\nto the created \"Individual subscription\" resource.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"The resource URI of the created VNF instance","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{"application/json":{"schema":{"description":"This type represents a subscription related to notifications about VNF lifecycle changes.\n","type":"object","required":["id","callbackUri","verbosity","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications about VNF lifecycle changes.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of \n the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdIds"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tVnfLcmOperationOccurrenceNotification -\tVnfIdentifierCreationNotification -\tVnfIdentifierDeletionNotification See note.\n","type":"array","items":{"type":"string","enum":["VnfLcmOperationOccurrenceNotification","VnfIdentifierCreationNotification","VnfIdentifierDeletionNotification"]}},"operationTypes":{"description":"Match particular VNF lifecycle operation types for the notification of type VnfLcmOperationOccurrenceNotification. May be present if the \"notificationTypes\" attribute contains the value \"VnfLcmOperationOccurrenceNotification\", and shall be absent otherwise.\n","type":"array","items":{"description":"The enumeration LcmOpType defines the permitted values to represent VNF lifecycle operation types in VNF lifecycle management operation occurrence resources and VNF lifecycle management operation occurrence notifications.\nValue | Description ------|------------ INSTANTIATE | Represents the \"Instantiate VNF\" LCM operation. SCALE | Represents the \"Scale VNF\" LCM operation. SCALE_TO_LEVEL | Represents the \"Scale VNF to Level\" LCM operation. CHANGE_FLAVOUR | Represents the \"Change VNF Flavour\" LCM operation. TERMINATE | Represents the \"Terminate VNF\" LCM operation. HEAL | Represents the \"Heal VNF\" LCM operation. OPERATE | Represents the \"Operate VNF\" LCM operation. CHANGE_EXT_CONN | Represents the \"Change external VNF connectivity\" LCM operation. MODIFY_INFO | Represents the \"Modify VNF Information\" LCM operation. CREATE_SNAPSHOT | Represents the \"Create VNF Snapshot\" LCM operation. REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot\" LCM operation. CHANGE_VNFPKG | Represents the \"Change current VNF package\" LCM operation. SELECT_DEPL_MODS | Represents the \"Select VNF deployable modules\" LCM operation\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","MODIFY_INFO","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","CHANGE_VNFPKG","SELECT_DEPL_MODS"]}},"operationStates":{"description":"Match particular LCM operation state values as reported in notifications of type VnfLcmOperationOccurrenceNotification. May be present if the \"notificationTypes\" attribute contains the value \"VnfLcmOperationOccurrenceNotification\", and shall be absent otherwise.\n","type":"array","items":{"description":"STARTING: The LCM operation is starting. PROCESSING: The LCM operation is currently in execution. COMPLETED: The LCM operation has been completed successfully. FAILED_TEMP: The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED: The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK: The LCM operation is currently being rolled back. ROLLED_BACK: The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible.\n","type":"string","enum":["STARTING","PROCESSING","COMPLETED","FAILED_TEMP","FAILED","ROLLING_BACK","ROLLED_BACK"]}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"verbosity":{"description":"The enumeration LcmOpOccNotificationVerbosityType provides values to control the verbosity of LCM operation occurrence notifications. * FULL: This signals a full notification which contains all change details. * SHORT: This signals a short notification which omits large-volume change details to reduce the size of data to be sent via the notification mechanism.\n","type":"string","enum":["FULL","SHORT"]},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"Subscriptions.Post.422":{"description":"422 Unprocessable Content\n\nShall be returned upon the following error: The content type of the message content is supported\nand the message content of a request contains syntactically correct data but the data cannot be\nprocessed.\nThe general cause for this error and its handling is specified in clause 6.4 of ETSI GS NFV-SOL 013,\nincluding rules for the presence of the response body.\nSpecifically in case of this resource, the response code 422 shall also be returned if the VNFM has\ntested the Notification endpoint as described in clause 5.4.20.3.2 and the test has failed.\nIn this case, the \"detail\" attribute in the \"ProblemDetails\" structure shall convey more\ninformation about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualSubscription.Get.200":{"description":"200 OK\nThe operation has completed successfully. The response body shall contain a representation of the\n\"Individual subscription\" resource.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a subscription related to notifications about VNF lifecycle changes.\n","type":"object","required":["id","callbackUri","verbosity","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications about VNF lifecycle changes.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of \n the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdIds"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tVnfLcmOperationOccurrenceNotification -\tVnfIdentifierCreationNotification -\tVnfIdentifierDeletionNotification See note.\n","type":"array","items":{"type":"string","enum":["VnfLcmOperationOccurrenceNotification","VnfIdentifierCreationNotification","VnfIdentifierDeletionNotification"]}},"operationTypes":{"description":"Match particular VNF lifecycle operation types for the notification of type VnfLcmOperationOccurrenceNotification. May be present if the \"notificationTypes\" attribute contains the value \"VnfLcmOperationOccurrenceNotification\", and shall be absent otherwise.\n","type":"array","items":{"description":"The enumeration LcmOpType defines the permitted values to represent VNF lifecycle operation types in VNF lifecycle management operation occurrence resources and VNF lifecycle management operation occurrence notifications.\nValue | Description ------|------------ INSTANTIATE | Represents the \"Instantiate VNF\" LCM operation. SCALE | Represents the \"Scale VNF\" LCM operation. SCALE_TO_LEVEL | Represents the \"Scale VNF to Level\" LCM operation. CHANGE_FLAVOUR | Represents the \"Change VNF Flavour\" LCM operation. TERMINATE | Represents the \"Terminate VNF\" LCM operation. HEAL | Represents the \"Heal VNF\" LCM operation. OPERATE | Represents the \"Operate VNF\" LCM operation. CHANGE_EXT_CONN | Represents the \"Change external VNF connectivity\" LCM operation. MODIFY_INFO | Represents the \"Modify VNF Information\" LCM operation. CREATE_SNAPSHOT | Represents the \"Create VNF Snapshot\" LCM operation. REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot\" LCM operation. CHANGE_VNFPKG | Represents the \"Change current VNF package\" LCM operation. SELECT_DEPL_MODS | Represents the \"Select VNF deployable modules\" LCM operation\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","MODIFY_INFO","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","CHANGE_VNFPKG","SELECT_DEPL_MODS"]}},"operationStates":{"description":"Match particular LCM operation state values as reported in notifications of type VnfLcmOperationOccurrenceNotification. May be present if the \"notificationTypes\" attribute contains the value \"VnfLcmOperationOccurrenceNotification\", and shall be absent otherwise.\n","type":"array","items":{"description":"STARTING: The LCM operation is starting. PROCESSING: The LCM operation is currently in execution. COMPLETED: The LCM operation has been completed successfully. FAILED_TEMP: The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED: The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK: The LCM operation is currently being rolled back. ROLLED_BACK: The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible.\n","type":"string","enum":["STARTING","PROCESSING","COMPLETED","FAILED_TEMP","FAILED","ROLLING_BACK","ROLLED_BACK"]}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"verbosity":{"description":"The enumeration LcmOpOccNotificationVerbosityType provides values to control the verbosity of LCM operation occurrence notifications. * FULL: This signals a full notification which contains all change details. * SHORT: This signals a short notification which omits large-volume change details to reduce the size of data to be sent via the notification mechanism.\n","type":"string","enum":["FULL","SHORT"]},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualSubscription.Delete.204":{"description":"204 NO CONTENT\nThe \"Individual subscription\" resource has been deleted successfully. The response body shall be empty.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{}},"VnfInstanceCreateSnapshot.Post.202":{"description":"202 ACCEPTED\nShall be returned when the request was accepted for processing, but the processing has not been completed.\nThe response body shall be empty. The HTTP response shall include a \"Location\" HTTP header that contains the URI\nof the newly-created \"VNF LCM operation occurrence\" resource corresponding to the operation.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"Used in redirection, or when a new resource has been created. This header field shall be present if the\nresponse status code is 201 or 3xx. In the present document this header field is also used if the response\nstatus code is 202 and a new resource was created.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{}},"VnfInstanceCreateSnapshot.Post.404":{"description":"404 Not Found\n\nShall be returned upon the following error: The API producer did not find a current representation\nfor the target resource or is not willing to disclose that one exists.\nThe general cause for this error and its handling is specified in clause 6.4 of ETSI\nGS NFV-SOL 013, including rules for the presence of the response body.\nSpecifically in case of this task resource, the response code 404 shall also be returned if the\ntask is not supported for the VNF instance represented by the parent resource, which means\nthat the task resource consequently does not exist.\nIn this case, the response body shall be present, and shall contain a ProblemDetails structure, in\nwhich the \"detail\" attribute shall convey more information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"VnfInstanceCreateSnapshot.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The operation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the VNF instance resource is in NOT_INSTANTIATED\nstate, or that another lifecycle management operation is ongoing.\nThe response body shall contain a ProblemDetails structure, in which the \"detail\" attribute shall\nconvey more information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"VnfInstanceCreateSnapshot.Post.422":{"description":"422 Unprocessable Content\n\nShall be returned upon the following error: The content type of the message content is supported\nand the message content of a request contains syntactically correct data but the data cannot be\nprocessed.\nThe general cause for this error and its handling is specified in clause 6.4 of ETSI\nGS NFV-SOL 013, including rules for the presence of the response body.\nSpecifically in case of this resource, the response code 422 shall also be returned if the provided\nidentifier of the target \"Individual VNF snapshot\" resource for the VNF snapshot is invalid.\nIn this case, the \"detail\" attribute in the \"ProblemDetails\" structure shall convey more\ninformation about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"VnfInstanceRevertToSnapshot.Post.202":{"description":"202 ACCEPTED\nShall be returned when the request was accepted for processing, but the processing has not been completed.\nThe response body shall be empty. The HTTP response shall include a \"Location\" HTTP header that contains the URI\nof the newly-created \"VNF LCM operation occurrence\" resource corresponding to the operation.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"Used in redirection, or when a new resource has been created. This header field shall be present if the\nresponse status code is 201 or 3xx. In the present document this header field is also used if the response\nstatus code is 202 and a new resource was created.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{}},"VnfInstanceRevertToSnapshot.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the VNF\ninstance resource is in NOT_INSTANTIATED\nstate, or that another lifecycle management\noperation is ongoing.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall\nconvey more information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"VnfSnapshots.Post.201":{"description":"201 CREATED\nShall be returned when an individual VNF snapshot resource has been created successfully.\nThe response body shall contain a representation of the new individual VNF snapshot resource, as defined in\nclause 5.5.2.21. The HTTP response shall include a \"Location\" HTTP header that contains the resource URI of the\nindividual VNF snapshot resource.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"Used in redirection, or when a new resource has been created. This header field shall be present if the\nresponse status code is 201 or 3xx. In the present document this header field is also used if the response\nstatus code is 202 and a new resource was created.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{"application/json":{"schema":{"description":"This type represents an individual VNF snapshot resource.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfSnapshotPkgId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfSnapshot":{"description":"This type represents a VNF snapshot.\n","type":"object","required":["id","vnfInstanceId","triggeredAt","vnfdId","vnfInfo","vnfcSnapshots"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"creationStartedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"creationFinishedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstance":{"description":"This type represents a VNF instance. * NOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist\n between the previous and the newly referred VNF package, i.e. when the new VNFD is\n changed with respect to the previous VNFD in other aspects than merely referencing\n to other VNF software images. In order to avoid misalignment of the VnfInstance with\n the current VNF's on-boarded VNF package, the values of attributes in the VnfInstance\n that have corresponding attributes in the VNFD shall be kept in sync with the values in the VNFD.\n* NOTE 2:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 3:\tThese attributes are sometimes also referred to as configuration parameters\n applicable to a VNF. Some of these are set prior to instantiation and cannot be modified\n if the VNF is instantiated, some are set prior to instantiation (are part of initial configuration)\n and can be modified later, and others can be set only after instantiation.\n The applicability of certain configuration may depend on the VNF and the required operation of\n the VNF at a certain point in time.\n* NOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child\n attributes of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared\n in the VNFD with a defined initial value. The defined initial values can be declared in the VNFD,\n and/or, in case of \"metadata\", obtained from the \"CreateVnfRequest\" structure. Child attributes of\n \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that have no defined initial value shall\n not be created, in order to be consistent with the semantics of the JSON Merge Patch method\n (see IETF RFC 7396) that interprets null values as deletion request.\n* NOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case\n of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding\n to the same VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc\n and externally-managed multi-site VL instance (refer to clause 5.5.3.5).\n* NOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity,\n they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n* NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual extCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the VNF \n LCM operation explicitly indicates the scale level for the aspect.\n* NOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n","type":"object","required":["id","vnfdId","vnfProvider","vnfProductName","vnfSoftwareVersion","vnfdVersion","instantiationState","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceName":{"description":"Name of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfInstanceDescription":{"description":"Human-readable description of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"Provider of the VNF and the VNFD. The value is copied from the VNFD.\n","type":"string"},"vnfProductName":{"description":"Name to identify the VNF Product. The value is copied from the VNFD.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateInfo":{"description":"This type provides input information related to certificate and certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateConfigurationInfo":{"description":"This type provides input information related to certificate management.\n","type":"object","required":["securityPolicy"],"properties":{"certificateBaseProfile":{"description":"This type provides input information to override certificate base profile for certificate management\nNOTE : At least one overriding attributes shall be present, otherwise shall be absent.\n","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"type":"string","description":"Issuer of certificates. See note."},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to subject of certificate.\n* NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of certification target subject FQDN. See note.","type":"string"},"organization":{"description":"Information of certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of certification target subject Country. See note.","type":"string"},"state":{"description":"Information of certification target subject State. See note.","type":"string"},"locality":{"description":"Information of certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"type":"string","description":"Basic constraints of certificates. See note.\n"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [7],clause 7.1.19.4). See note","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}},"securityPolicy":{"description":"Information for security policy to be satisfied for certificate.\n","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"integer"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"integer"}}}},"delegationSupportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"cmfInfo":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["id","endPoint","supportedProtocol"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"endPoint":{"description":"End point of CMF instance.","type":"object","required":["ipAddress","link"],"properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocols":{"description":"Supported protocol by CMF instance.","type":"array","items":{"type":"string","enum":["CMP","CMPv2","EST","SCEP"]}},"certificateChain":{"description":"Certificate chain that this CMF provides.","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"certificateContents":{"description":"Information for contents of issued certificates. The information contained in this attribute may be updated over time during the VNF LCM, e.g. certificate(s) renewal.\n","type":"array","items":{"description":"This type provides input information related to certificate content.\n","type":"object","required":["id","certificateDescId","certificateType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certficateDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"certificateType":{"description":"Type of this certificate.","type":"string","enum":["VNFCI_CERT","VNFOAM_CERT"]},"supportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"version":{"description":"A version.\n","type":"string"},"serialNumber":{"description":"Serial number of this certificate.","type":"integer"},"signatureAlgorithm":{"description":"Algorithm of this certificate's signature.","type":"string"},"issuer":{"description":"Issuer of this certificate.","type":"string"},"notBefore":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"notAfter":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"subject":{"description":"Subject of this certificate.","type":"string"},"publicKeyAlgorithm":{"description":"Algorithm of this certificate's public key.","type":"string"},"publicKey":{"description":"Public key of this certificate.","type":"string"},"certificateExtensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"instantiationState":{"description":"The instantiation state of the VNF.\n","type":"string","enum":["NOT_INSTANTIATED","INSTANTIATED"]},"instantiatedVnfInfo":{"description":"Information specific to an instantiated VNF instance. This attribute shall be present if the instantiateState attribute value is INSTANTIATED.\n","type":"object","required":["flavourId","vnfState","extCpInfo"],"properties":{"flavourId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfState":{"description":"STARTED: The VNF instance is up and running. STOPPED: The VNF instance has been shut down.\n","type":"string","enum":["STARTED","STOPPED"]},"vnfPowerState":{"description":"This type represents information about the power state of a VNF instance.\n","type":"object","required":["powerProfileId","name"],"properties":{"powerProfileId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Name of the power profile as provided in the VNFD.\n","type":"string"},"powerConsumptionInfo":{"description":"This type represents information about estimated power consumption of the resources associated with the power profile, as provided in the VNFD.\n","type":"object","required":["minPowerConsumption","maxPowerConsumption","averagePowerConsumption"],"properties":{"minPowerConsumption":{"description":"Minimum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"maxPowerConsumption":{"description":"Maximum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"averagePowerConsumption":{"description":"Average power consumption of this power profile. Unit is KW/h.\n","type":"integer"}}}}},"scaleStatus":{"description":"Scale status of the VNF, one entry per aspect. Represents for every scaling aspect how \"big\" the VNF has been scaled w.r.t. that aspect. This attribute shall be present if the VNF supports scaling. See clause B.2 for an explanation of VNF scaling. For an aspect that has not been deployed because the related deployableModule has not been selected, it indicates the scale level that has been requested in the instantiation or in a scaling operation, or, if none has been requested in any of them, the scale level applicable to the aspect based on the default instantiation level. See note 8.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleLevel":{"description":"Indicates the scale level. The minimum value shall be 0 and the maximum value shall be <= maxScaleLevel as described in the VNFD.\n","type":"integer"}}}},"maxScaleLevels":{"description":"Maximum allowed scale levels of the VNF, one entry per aspect. This attribute shall be present if the VNF supports scaling.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleLevel":{"description":"Indicates the scale level. The minimum value shall be 0 and the maximum value shall be <= maxScaleLevel as described in the VNFD.\n","type":"integer"}}}},"selectedDeployableModule":{"description":"References a currently selected deployable module, as defined in the VNFD, that has already completed the instantiation of its VNFCs\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceCapacityDefinition":{"description":"Shows current values of VDU attributes related to resource capacity, if different to the default values from the VNFD, as indicated in the (one or more) request(s) of all completed VNF LCM operation(s) that contain this attribute. If an attribute value has been modified multiple times, only the last value is shown. The values indicated in this attribute are applicable to all VNFC instances based on the VDU to which the resourceCapacityDefinition is related.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes. The tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request. At most one tag can be included when the data type is used in a VNF LCM operation request. When the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced. VALUES •\tCOMPUTE •\tSTORAGE •\tOSCONTAINER","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute ‘type’ indicates OSCONTAINER and absent otherwise.","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource.See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resources_property in the VNFD that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["resourceTemplateId"]},{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD for this virtual compute descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"extCpInfo":{"description":"Information about the external CPs exposed by the VNF instance. When trunking is enabled, the list of entries includes both, external CPs corresponding to parent ports of a trunk, and external CPs associated to sub-ports of a trunk. See note 7.\n","type":"array","minItems":1,"items":{"description":"This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n","type":"object","required":["id","cpdId","cpConfigId","cpProtocolInfo"],"oneOf":[{"required":["associatedVnfcCpId"]},{"required":["associatedVipCpId"]},{"required":["associatedVnfVirtualLinkId"]}],"properties":{"id":{"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"},"cpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extLinkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"associatedVnfcCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVipCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVirtualCpId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"associatedVnfVirtualLinkId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 3 and 4. It shall be present if the external CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"certificateContentId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cpSecurityGroupInfo":{"description":"This type provides the list of active security group rules applied to an external CP instance. The type identifies which \"SecurityGroupRule\" specified in the VNFD are activated and the values of its attributes.\n","type":"object","required":["securityGroupRuleId","etherType","protocol","portRangeMin","portRangeMax"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"description":{"description":"Human readable description of the security group rule.\n","type":"string"},"etherType":{"description":"Indicates the protocol carried over the Ethernet layer. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"protocol":{"description":"Indicates the protocol carried over the IP layer. Permitted values: any protocol defined in the IANA protocol registry (refer to clause 9.10.1.2 ofd ETSI GS NFV-SOL 001 for further information).\n","type":"string"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule.\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule.\n","type":"integer"}}}}}},"vipCpInfo":{"description":"VIP CPs that are part of the VNF instance. Shall be present when that particular VIP CP of the VNFC instance is associated to an external CP of the VNF instance.\nMay be present otherwise.\n","type":"array","items":{"description":"This type provides information related to virtual IP CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["cpInstanceId","cpdId"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for layer 3. There may be one cpProtocolInfo for layer 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"associatedVnfcCpIds":{"description":"Identifiers of the VnfcCps that share the virtual IP address allocated to the VIP CP instance. See note.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualCpInfo":{"description":"Virtual CPs that are part of the VNF instance. Shall be present when a particular virtual CP is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","items":{"description":"This type provides information related to a virtual CP instance of a VNF.\n* NOTE 1: A consumer of the VNF LCM interface can learn the actual VNFC instances implementing the service accessible via the virtual CP instance by querying the \"vnfcResourceInfo\" from the \"InstantiatedVnfInfo\" \n and filtering by corresponding \"vduIds\" values.\n* NOTE 2: The information can be omitted because it is already available as part of the external CP information in the VnfExtCpInfo structure.\n","type":"object","required":["cpInstanceId","cpdId","resourceHandle","vduIds"],"properties":{"cpInstanceId":{"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"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for each layer protocol supported. This attribute may be omitted if the virtual CP is exposed as an external CP. See note 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vduIds":{"description":"Reference to the VDU(s) which implement the service accessible via the virtual CP instance. See note.\n","type":"array","minItems":1,"items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"additionalServiceInfo":{"description":"Additional service identification information of the virtual CP instance.\n","type":"array","items":{"description":"This type provides additional service information of the virtual CP instance used to expose properties of the virtual CP to NFV-MANO.\nNOTE: This attribute shall only be present if additional information is needed to identify the service termination within the VNF, such as for example a URL path information in an HTTP request required \n to allow a single virtual CP IP address to be used for several HTTP based services that use the \n same port number.\n","type":"object","required":["portInfo"],"properties":{"portInfo":{"description":"Service port numbers exposed by the virtual CP instance.\n","minItems":1,"type":"array","items":{"description":"This type describes the service identifying port properties exposed by the virtual CP instance.\n","type":"object","required":["name","port","portConfigurable"],"properties":{"name":{"description":"The name of the port exposed by the virtual CP instance.\n","type":"string"},"protocol":{"description":"The L4 protocol for this port exposed by the virtual CP instance.\nPermitted values: - TCP - UDP - SCTP\n","type":"string","enum":["TCP","UDP","SCTP"]},"port":{"description":"The L4 port number exposed by the virtual CP instance.\n","type":"integer"},"portConfigurable":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"}}}},"serviceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"extVirtualLinkInfo":{"description":"Information about the external VLs the VNF instance is connected to.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD. The key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO. The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5 and 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored.\n\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for \n Kubernetes® that supports configuration of address pools for load balancer services.\n\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"string"},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"string"}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"routingResource":{"description":"Network resources that provide the forwarding/routing capabilities associated to the network resource realizing this VL.\n","type":"array","items":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}}},"extManagedVirtualLinkInfo":{"description":"Information about the externally managed internal VLs of the VNF instance. See note 5 and note 6. It is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed multi-site VL instance (refer to clause 5.5.3.5). Even though externally-managed internal VLs are also used for VNF-internal connectivity, they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n","type":"array","items":{"description":"This type provides information about an externally-managed virtual link. *NOTE: Both vnfLinkPort and vnfNetAttDefResource can be present in an ExtManagedVirtualLinkInfo to indicate that a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPorts":{"description":"Link ports of this VL.See note.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"vnfNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"routingResource":{"description":"Network resources that provide the forwarding/routing capabilities associated to the network resource realizing this VL.\n","type":"array","items":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}}},"monitoringParameters":{"description":"Active monitoring parameters.\n","type":"array","items":{"type":"object","required":["id","performanceMetric"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human readable name of the monitoring parameter, as defined in the VNFD.\n","type":"string"},"performanceMetric":{"description":"Performance metric that is monitored. This attribute shall contain the related \"Measurement Name\" value as defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"}}}},"localizationLanguage":{"description":"Information about localization language of the VNF (includes e.g. strings in the VNFD). The localization languages supported by a VNF can be declared in the VNFD, and localization language selection can take place at instantiation time. The value shall comply with the format defined in IETF RFC 5646.\n","type":"string"},"vnfcResourceInfo":{"description":"Information about the virtualised compute and storage resources used by the VNFCs of the VNF instance.\n","type":"array","items":{"description":"This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure \n of information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n - For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n - For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\n\n* NOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an internal VL that\n exposes an external CP. A VNFC CP is \"exposed as\" an external CP if it is connected directly\n to an external VL.\n* NOTE 3:\tThe information can be omitted because it is already available as part of the external CP information. * NOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\" structure by \n an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVnfc\"\n structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to \n this LCM operation occurrence.\n* NOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment \n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build \n a link redundant mated pair in SR-IOV cases.\n* NOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. * NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n","type":"object","required":["id","vduId","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"storageResourceIds":{"description":"References to the VirtualStorage resources or references to Storage MCIO(s). The value refers to a VirtualStorageResourceInfo item in the VnfInstance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcCpInfo":{"description":"All the CPs of the VNFC instance. See note 7.\n","type":"array","items":{"type":"object","required":["id","cpdId"],"properties":{"id":{"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"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP. May be omitted if the VNFC CP is exposed as an external CP. The information can be omitted because it is already available as part of the external CP information. See note 3.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"parentCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 5 and 6. It shall be present if the internal CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfVirtualLinkResourceInfo":{"description":"Information about the virtualised network resources used by the VLs of the VNF instance. See note 6. Even though externally-managed internal VLs are also used for VNF-internal connectivity, they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by an internal VL instance in a VNF instance. NOTE: If only the value or the presence of this attribute is changed in the \"VnfVirtualLinkResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a \n related \"AffectedVirtualLink\" structure in the VNF LCM operation occurrence notifications or the \n \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource","vnfLinkPorts"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLinkPorts":{"description":"Links ports of this VL. Shall be present when the linkPort is used for external connectivity by the VNF (refer to VnfLinkPortInfo). May be present otherwise.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualStorageResourceInfo":{"description":"Information on the virtualised storage resource(s) used as storage for the VNF instance.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance.\nNOTE: If only the value or the presence of this attribute is changed in the \"VirtualStorageResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVirtualStorage\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","virtualStorageDescId","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"vnfcInfo":{"description":"Information about the VNFC instances.\n","type":"array","items":{"description":"This type represents the information about a VNFC instance that is part of a VNF instance. * NOTE:\tThis allows to represent the error condition that a VNFC instance has lost its resources.\n","type":"object","required":["id","vduId","vnfcState"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcResourceInfoId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcState":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mcioInfo":{"description":"Information on the MCIO(s) representing VNFC instance(s) realized by one or a set of OS containers and created from the same VDU for the VNF instance.\n","type":"array","items":{"description":"This type provides information about an MCIO representing the set of VNFC instances realized by one or a set of OS containers which have been created based on the same VDU. Within the CISM, an MCIO controller monitors the actual state of an MCIO representing the set of VNFC instances realized by one or a set of OS containers and compare it to the desired state. For an MCIO related to a VDU that has the attribute \"isNumOfInstancesClusterBased\" set to FALSE the desired state is specified in the respective declarative descriptor. For an MCIO related to a VDU that has the attribute \"isNumOfInstancesClusterBased\" set to TRUE, the desired state is determined by the number of CIS-nodes in the cluster that fulfil the VDU requirements. It triggers actions toward the CIS to align the actual to the desired state. Monitoring the actual state includes monitoring the number of MCIO instances available at any specific point in time. In addition, an MCIO controller maintains properties and runtime information on the MCIO instances which have been created based on the same VDU. The McioInfo data structure provides the runtime information on the MCIOs obtained from the MCIO controller.\nNOTE: There are different types of MCIOs. The set of VNFC instances based on the same VDU is represented by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type \n of MCIO, e.g. a POD.\n\nRuntime information of the set of OS containers realizing an individual VNFC instance is not part of the McioInfo data structure; such runtime information is provided in the ResourceHandle data structure referenced from the VnfcResourceInfo. The McioInfo does not provide runtime information of a constituent VNFC instance created based on a specific VDU.\nNOTE 1: The type of MCIO as specified in the declarative descriptor of the MCIO, and that can be read from the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the \n “kind” property of the declarative descriptor.\nNOTE 2: If the attribute additionalInfo is present, it may contain runtime information on the actual and desired state of the MCIO(s). \nNOTE 3: When the container infrastructure service is a Kubernetes® instance, the mcioId is the combined values from the kind and name fields of the Kubernetes resource object, separated by a slash. \n Example: \"Deployment/abcd\". \nNOTE 4: When the container infrastructure service is a Kubernetes® instance, the mcioName is the name field of the resource object.\n","type":"object","required":["mcioId","mcioName","mcioNamespace","vduId","cismId","mcioType","desiredInstances","availableInstances"],"properties":{"mcioId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioName":{"description":"Human readable name of this MCIO. See note 4.\n","type":"string"},"mcioNamespace":{"description":"Namespace of this MCIO.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cismId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioType":{"description":"The type of MCIO. Specific values, their semantics and associated MCIO types are defined in clause 5.5.4.9. Additional values are also permitted. See note 1.\n","type":"string","enum":["Deployment","StatefulSet","DaemonSet"]},"desiredInstances":{"description":"Number of desired MCIO instances.\n","type":"integer"},"availableInstances":{"description":"Number of available MCIO instances.\n","type":"integer"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"vnfPaasServiceInfo":{"description":"Information on the PaaS Services assigned and used by the VNF instance.\n","type":"array","items":{"description":"This type provides information about a PaaS Service that is used by a VNF instance. The PaasServiceInfo is comprised of various sets of information. Some information comes from the VNFD, other information comes from the PaaS Service assets provided by the NFVO to the VNFM, and other information is provided at runtime information about the usage of the PaaS Service.\n","type":"object","required":["id","paasServiceId","paasServiceType","paasServiceRequestId","paasServiceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceType":{"description":"The type of PaaS Service. The value of this attribute is expected to be matched against values of the registered PaaS Services in the PSR.\n","type":"string"},"paasServiceVersion":{"description":"A version.\n","type":"string"},"paasServiceRequestId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"paasServiceHandle":{"description":"This type provides information enabling the access and use of the PaaS Service by the VNF instance. The type and format of the handle depends on the form that the PaaS Service is formed.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"indicators":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"instantiate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"terminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"heal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"operate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"createSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"revertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeCurrentVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"recentVnfLcmOperationLinks":{"description":"Links to the most recent LCM operation occurrences related to this resource. See note 9.\n","type":"object","properties":{"recentVnfLcmOperation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmInstantiation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmTerminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmHeal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmOperate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmModifyInfo":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmCreateSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmRevertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmSelectDplMods":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}},"vnfcSnapshots":{"description":"Information about VNFC snapshots constituting this VNF snapshot.\n","type":"array","items":{"description":"This type represents a VNFC snapshot. * NOTE 1:\tThe identifier of the compute snapshot resource is assigned during creation of a VNFC\n snapshot being returned from the VIM as output data in the response message of the individual\n resource operations. This attribute shall only be present for a VNFC snapshot that has been\n newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n NOTE 2:\tThe identifier of the storage snapshot resource is assigned during creation of a VNFC snapshot\n being returned from the VIM as output data in the response message of the individual resource\n operations. This attribute shall only be present for a VNFC snapshot with an associated storage\n resource and that has been newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n","type":"object","required":["id","vnfcInstanceId","creationStartedAt","vnfcResourceInfoId"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"creationStartedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"creationFinishedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfcResourceInfoId":{"description":"This type represents the information about a VNFC instance that is part of a VNF instance. * NOTE:\tThis allows to represent the error condition that a VNFC instance has lost its resources.\n","type":"object","required":["id","vduId","vnfcState"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcResourceInfoId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcState":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"computeSnapshotResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"storageSnapshotResources":{"description":"Mapping of the storage resources associated to the VNFC with the storage snapshot resources.\n","type":"object","required":["storageResourceId"],"properties":{"storageResourceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"storageSnapshotResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"takenFrom":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"VnfSnapshots.Get.200":{"description":"200 OK\nShall be returned when information about zero or more VNF snapshots was queried successfully.\nThe response body shall contain in an array the representations of zero or more individual VNF\nsnapshot resources, as defined in clause 5.5.2.21.\n\nIf the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013\nfor this resource, inclusion of the Link HTTP header in this response shall follow the provisions\nin clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents an individual VNF snapshot resource.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfSnapshotPkgId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfSnapshot":{"description":"This type represents a VNF snapshot.\n","type":"object","required":["id","vnfInstanceId","triggeredAt","vnfdId","vnfInfo","vnfcSnapshots"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"creationStartedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"creationFinishedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstance":{"description":"This type represents a VNF instance. * NOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist\n between the previous and the newly referred VNF package, i.e. when the new VNFD is\n changed with respect to the previous VNFD in other aspects than merely referencing\n to other VNF software images. In order to avoid misalignment of the VnfInstance with\n the current VNF's on-boarded VNF package, the values of attributes in the VnfInstance\n that have corresponding attributes in the VNFD shall be kept in sync with the values in the VNFD.\n* NOTE 2:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 3:\tThese attributes are sometimes also referred to as configuration parameters\n applicable to a VNF. Some of these are set prior to instantiation and cannot be modified\n if the VNF is instantiated, some are set prior to instantiation (are part of initial configuration)\n and can be modified later, and others can be set only after instantiation.\n The applicability of certain configuration may depend on the VNF and the required operation of\n the VNF at a certain point in time.\n* NOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child\n attributes of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared\n in the VNFD with a defined initial value. The defined initial values can be declared in the VNFD,\n and/or, in case of \"metadata\", obtained from the \"CreateVnfRequest\" structure. Child attributes of\n \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that have no defined initial value shall\n not be created, in order to be consistent with the semantics of the JSON Merge Patch method\n (see IETF RFC 7396) that interprets null values as deletion request.\n* NOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case\n of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding\n to the same VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc\n and externally-managed multi-site VL instance (refer to clause 5.5.3.5).\n* NOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity,\n they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n* NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual extCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the VNF \n LCM operation explicitly indicates the scale level for the aspect.\n* NOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n","type":"object","required":["id","vnfdId","vnfProvider","vnfProductName","vnfSoftwareVersion","vnfdVersion","instantiationState","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceName":{"description":"Name of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfInstanceDescription":{"description":"Human-readable description of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"Provider of the VNF and the VNFD. The value is copied from the VNFD.\n","type":"string"},"vnfProductName":{"description":"Name to identify the VNF Product. The value is copied from the VNFD.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateInfo":{"description":"This type provides input information related to certificate and certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateConfigurationInfo":{"description":"This type provides input information related to certificate management.\n","type":"object","required":["securityPolicy"],"properties":{"certificateBaseProfile":{"description":"This type provides input information to override certificate base profile for certificate management\nNOTE : At least one overriding attributes shall be present, otherwise shall be absent.\n","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"type":"string","description":"Issuer of certificates. See note."},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to subject of certificate.\n* NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of certification target subject FQDN. See note.","type":"string"},"organization":{"description":"Information of certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of certification target subject Country. See note.","type":"string"},"state":{"description":"Information of certification target subject State. See note.","type":"string"},"locality":{"description":"Information of certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"type":"string","description":"Basic constraints of certificates. See note.\n"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [7],clause 7.1.19.4). See note","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}},"securityPolicy":{"description":"Information for security policy to be satisfied for certificate.\n","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"integer"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"integer"}}}},"delegationSupportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"cmfInfo":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["id","endPoint","supportedProtocol"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"endPoint":{"description":"End point of CMF instance.","type":"object","required":["ipAddress","link"],"properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocols":{"description":"Supported protocol by CMF instance.","type":"array","items":{"type":"string","enum":["CMP","CMPv2","EST","SCEP"]}},"certificateChain":{"description":"Certificate chain that this CMF provides.","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"certificateContents":{"description":"Information for contents of issued certificates. The information contained in this attribute may be updated over time during the VNF LCM, e.g. certificate(s) renewal.\n","type":"array","items":{"description":"This type provides input information related to certificate content.\n","type":"object","required":["id","certificateDescId","certificateType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certficateDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"certificateType":{"description":"Type of this certificate.","type":"string","enum":["VNFCI_CERT","VNFOAM_CERT"]},"supportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"version":{"description":"A version.\n","type":"string"},"serialNumber":{"description":"Serial number of this certificate.","type":"integer"},"signatureAlgorithm":{"description":"Algorithm of this certificate's signature.","type":"string"},"issuer":{"description":"Issuer of this certificate.","type":"string"},"notBefore":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"notAfter":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"subject":{"description":"Subject of this certificate.","type":"string"},"publicKeyAlgorithm":{"description":"Algorithm of this certificate's public key.","type":"string"},"publicKey":{"description":"Public key of this certificate.","type":"string"},"certificateExtensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"instantiationState":{"description":"The instantiation state of the VNF.\n","type":"string","enum":["NOT_INSTANTIATED","INSTANTIATED"]},"instantiatedVnfInfo":{"description":"Information specific to an instantiated VNF instance. This attribute shall be present if the instantiateState attribute value is INSTANTIATED.\n","type":"object","required":["flavourId","vnfState","extCpInfo"],"properties":{"flavourId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfState":{"description":"STARTED: The VNF instance is up and running. STOPPED: The VNF instance has been shut down.\n","type":"string","enum":["STARTED","STOPPED"]},"vnfPowerState":{"description":"This type represents information about the power state of a VNF instance.\n","type":"object","required":["powerProfileId","name"],"properties":{"powerProfileId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Name of the power profile as provided in the VNFD.\n","type":"string"},"powerConsumptionInfo":{"description":"This type represents information about estimated power consumption of the resources associated with the power profile, as provided in the VNFD.\n","type":"object","required":["minPowerConsumption","maxPowerConsumption","averagePowerConsumption"],"properties":{"minPowerConsumption":{"description":"Minimum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"maxPowerConsumption":{"description":"Maximum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"averagePowerConsumption":{"description":"Average power consumption of this power profile. Unit is KW/h.\n","type":"integer"}}}}},"scaleStatus":{"description":"Scale status of the VNF, one entry per aspect. Represents for every scaling aspect how \"big\" the VNF has been scaled w.r.t. that aspect. This attribute shall be present if the VNF supports scaling. See clause B.2 for an explanation of VNF scaling. For an aspect that has not been deployed because the related deployableModule has not been selected, it indicates the scale level that has been requested in the instantiation or in a scaling operation, or, if none has been requested in any of them, the scale level applicable to the aspect based on the default instantiation level. See note 8.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleLevel":{"description":"Indicates the scale level. The minimum value shall be 0 and the maximum value shall be <= maxScaleLevel as described in the VNFD.\n","type":"integer"}}}},"maxScaleLevels":{"description":"Maximum allowed scale levels of the VNF, one entry per aspect. This attribute shall be present if the VNF supports scaling.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleLevel":{"description":"Indicates the scale level. The minimum value shall be 0 and the maximum value shall be <= maxScaleLevel as described in the VNFD.\n","type":"integer"}}}},"selectedDeployableModule":{"description":"References a currently selected deployable module, as defined in the VNFD, that has already completed the instantiation of its VNFCs\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceCapacityDefinition":{"description":"Shows current values of VDU attributes related to resource capacity, if different to the default values from the VNFD, as indicated in the (one or more) request(s) of all completed VNF LCM operation(s) that contain this attribute. If an attribute value has been modified multiple times, only the last value is shown. The values indicated in this attribute are applicable to all VNFC instances based on the VDU to which the resourceCapacityDefinition is related.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes. The tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request. At most one tag can be included when the data type is used in a VNF LCM operation request. When the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced. VALUES •\tCOMPUTE •\tSTORAGE •\tOSCONTAINER","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute ‘type’ indicates OSCONTAINER and absent otherwise.","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource.See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resources_property in the VNFD that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["resourceTemplateId"]},{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD for this virtual compute descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"extCpInfo":{"description":"Information about the external CPs exposed by the VNF instance. When trunking is enabled, the list of entries includes both, external CPs corresponding to parent ports of a trunk, and external CPs associated to sub-ports of a trunk. See note 7.\n","type":"array","minItems":1,"items":{"description":"This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n","type":"object","required":["id","cpdId","cpConfigId","cpProtocolInfo"],"oneOf":[{"required":["associatedVnfcCpId"]},{"required":["associatedVipCpId"]},{"required":["associatedVnfVirtualLinkId"]}],"properties":{"id":{"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"},"cpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extLinkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"associatedVnfcCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVipCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVirtualCpId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"associatedVnfVirtualLinkId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 3 and 4. It shall be present if the external CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"certificateContentId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cpSecurityGroupInfo":{"description":"This type provides the list of active security group rules applied to an external CP instance. The type identifies which \"SecurityGroupRule\" specified in the VNFD are activated and the values of its attributes.\n","type":"object","required":["securityGroupRuleId","etherType","protocol","portRangeMin","portRangeMax"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"description":{"description":"Human readable description of the security group rule.\n","type":"string"},"etherType":{"description":"Indicates the protocol carried over the Ethernet layer. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"protocol":{"description":"Indicates the protocol carried over the IP layer. Permitted values: any protocol defined in the IANA protocol registry (refer to clause 9.10.1.2 ofd ETSI GS NFV-SOL 001 for further information).\n","type":"string"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule.\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule.\n","type":"integer"}}}}}},"vipCpInfo":{"description":"VIP CPs that are part of the VNF instance. Shall be present when that particular VIP CP of the VNFC instance is associated to an external CP of the VNF instance.\nMay be present otherwise.\n","type":"array","items":{"description":"This type provides information related to virtual IP CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["cpInstanceId","cpdId"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for layer 3. There may be one cpProtocolInfo for layer 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"associatedVnfcCpIds":{"description":"Identifiers of the VnfcCps that share the virtual IP address allocated to the VIP CP instance. See note.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualCpInfo":{"description":"Virtual CPs that are part of the VNF instance. Shall be present when a particular virtual CP is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","items":{"description":"This type provides information related to a virtual CP instance of a VNF.\n* NOTE 1: A consumer of the VNF LCM interface can learn the actual VNFC instances implementing the service accessible via the virtual CP instance by querying the \"vnfcResourceInfo\" from the \"InstantiatedVnfInfo\" \n and filtering by corresponding \"vduIds\" values.\n* NOTE 2: The information can be omitted because it is already available as part of the external CP information in the VnfExtCpInfo structure.\n","type":"object","required":["cpInstanceId","cpdId","resourceHandle","vduIds"],"properties":{"cpInstanceId":{"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"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for each layer protocol supported. This attribute may be omitted if the virtual CP is exposed as an external CP. See note 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vduIds":{"description":"Reference to the VDU(s) which implement the service accessible via the virtual CP instance. See note.\n","type":"array","minItems":1,"items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"additionalServiceInfo":{"description":"Additional service identification information of the virtual CP instance.\n","type":"array","items":{"description":"This type provides additional service information of the virtual CP instance used to expose properties of the virtual CP to NFV-MANO.\nNOTE: This attribute shall only be present if additional information is needed to identify the service termination within the VNF, such as for example a URL path information in an HTTP request required \n to allow a single virtual CP IP address to be used for several HTTP based services that use the \n same port number.\n","type":"object","required":["portInfo"],"properties":{"portInfo":{"description":"Service port numbers exposed by the virtual CP instance.\n","minItems":1,"type":"array","items":{"description":"This type describes the service identifying port properties exposed by the virtual CP instance.\n","type":"object","required":["name","port","portConfigurable"],"properties":{"name":{"description":"The name of the port exposed by the virtual CP instance.\n","type":"string"},"protocol":{"description":"The L4 protocol for this port exposed by the virtual CP instance.\nPermitted values: - TCP - UDP - SCTP\n","type":"string","enum":["TCP","UDP","SCTP"]},"port":{"description":"The L4 port number exposed by the virtual CP instance.\n","type":"integer"},"portConfigurable":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"}}}},"serviceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"extVirtualLinkInfo":{"description":"Information about the external VLs the VNF instance is connected to.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD. The key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO. The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5 and 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored.\n\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for \n Kubernetes® that supports configuration of address pools for load balancer services.\n\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"string"},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"string"}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"routingResource":{"description":"Network resources that provide the forwarding/routing capabilities associated to the network resource realizing this VL.\n","type":"array","items":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}}},"extManagedVirtualLinkInfo":{"description":"Information about the externally managed internal VLs of the VNF instance. See note 5 and note 6. It is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed multi-site VL instance (refer to clause 5.5.3.5). Even though externally-managed internal VLs are also used for VNF-internal connectivity, they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n","type":"array","items":{"description":"This type provides information about an externally-managed virtual link. *NOTE: Both vnfLinkPort and vnfNetAttDefResource can be present in an ExtManagedVirtualLinkInfo to indicate that a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPorts":{"description":"Link ports of this VL.See note.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"vnfNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"routingResource":{"description":"Network resources that provide the forwarding/routing capabilities associated to the network resource realizing this VL.\n","type":"array","items":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}}},"monitoringParameters":{"description":"Active monitoring parameters.\n","type":"array","items":{"type":"object","required":["id","performanceMetric"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human readable name of the monitoring parameter, as defined in the VNFD.\n","type":"string"},"performanceMetric":{"description":"Performance metric that is monitored. This attribute shall contain the related \"Measurement Name\" value as defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"}}}},"localizationLanguage":{"description":"Information about localization language of the VNF (includes e.g. strings in the VNFD). The localization languages supported by a VNF can be declared in the VNFD, and localization language selection can take place at instantiation time. The value shall comply with the format defined in IETF RFC 5646.\n","type":"string"},"vnfcResourceInfo":{"description":"Information about the virtualised compute and storage resources used by the VNFCs of the VNF instance.\n","type":"array","items":{"description":"This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure \n of information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n - For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n - For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\n\n* NOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an internal VL that\n exposes an external CP. A VNFC CP is \"exposed as\" an external CP if it is connected directly\n to an external VL.\n* NOTE 3:\tThe information can be omitted because it is already available as part of the external CP information. * NOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\" structure by \n an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVnfc\"\n structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to \n this LCM operation occurrence.\n* NOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment \n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build \n a link redundant mated pair in SR-IOV cases.\n* NOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. * NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n","type":"object","required":["id","vduId","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"storageResourceIds":{"description":"References to the VirtualStorage resources or references to Storage MCIO(s). The value refers to a VirtualStorageResourceInfo item in the VnfInstance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcCpInfo":{"description":"All the CPs of the VNFC instance. See note 7.\n","type":"array","items":{"type":"object","required":["id","cpdId"],"properties":{"id":{"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"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP. May be omitted if the VNFC CP is exposed as an external CP. The information can be omitted because it is already available as part of the external CP information. See note 3.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"parentCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 5 and 6. It shall be present if the internal CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfVirtualLinkResourceInfo":{"description":"Information about the virtualised network resources used by the VLs of the VNF instance. See note 6. Even though externally-managed internal VLs are also used for VNF-internal connectivity, they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by an internal VL instance in a VNF instance. NOTE: If only the value or the presence of this attribute is changed in the \"VnfVirtualLinkResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a \n related \"AffectedVirtualLink\" structure in the VNF LCM operation occurrence notifications or the \n \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource","vnfLinkPorts"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLinkPorts":{"description":"Links ports of this VL. Shall be present when the linkPort is used for external connectivity by the VNF (refer to VnfLinkPortInfo). May be present otherwise.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualStorageResourceInfo":{"description":"Information on the virtualised storage resource(s) used as storage for the VNF instance.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance.\nNOTE: If only the value or the presence of this attribute is changed in the \"VirtualStorageResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVirtualStorage\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","virtualStorageDescId","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"vnfcInfo":{"description":"Information about the VNFC instances.\n","type":"array","items":{"description":"This type represents the information about a VNFC instance that is part of a VNF instance. * NOTE:\tThis allows to represent the error condition that a VNFC instance has lost its resources.\n","type":"object","required":["id","vduId","vnfcState"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcResourceInfoId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcState":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mcioInfo":{"description":"Information on the MCIO(s) representing VNFC instance(s) realized by one or a set of OS containers and created from the same VDU for the VNF instance.\n","type":"array","items":{"description":"This type provides information about an MCIO representing the set of VNFC instances realized by one or a set of OS containers which have been created based on the same VDU. Within the CISM, an MCIO controller monitors the actual state of an MCIO representing the set of VNFC instances realized by one or a set of OS containers and compare it to the desired state. For an MCIO related to a VDU that has the attribute \"isNumOfInstancesClusterBased\" set to FALSE the desired state is specified in the respective declarative descriptor. For an MCIO related to a VDU that has the attribute \"isNumOfInstancesClusterBased\" set to TRUE, the desired state is determined by the number of CIS-nodes in the cluster that fulfil the VDU requirements. It triggers actions toward the CIS to align the actual to the desired state. Monitoring the actual state includes monitoring the number of MCIO instances available at any specific point in time. In addition, an MCIO controller maintains properties and runtime information on the MCIO instances which have been created based on the same VDU. The McioInfo data structure provides the runtime information on the MCIOs obtained from the MCIO controller.\nNOTE: There are different types of MCIOs. The set of VNFC instances based on the same VDU is represented by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type \n of MCIO, e.g. a POD.\n\nRuntime information of the set of OS containers realizing an individual VNFC instance is not part of the McioInfo data structure; such runtime information is provided in the ResourceHandle data structure referenced from the VnfcResourceInfo. The McioInfo does not provide runtime information of a constituent VNFC instance created based on a specific VDU.\nNOTE 1: The type of MCIO as specified in the declarative descriptor of the MCIO, and that can be read from the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the \n “kind” property of the declarative descriptor.\nNOTE 2: If the attribute additionalInfo is present, it may contain runtime information on the actual and desired state of the MCIO(s). \nNOTE 3: When the container infrastructure service is a Kubernetes® instance, the mcioId is the combined values from the kind and name fields of the Kubernetes resource object, separated by a slash. \n Example: \"Deployment/abcd\". \nNOTE 4: When the container infrastructure service is a Kubernetes® instance, the mcioName is the name field of the resource object.\n","type":"object","required":["mcioId","mcioName","mcioNamespace","vduId","cismId","mcioType","desiredInstances","availableInstances"],"properties":{"mcioId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioName":{"description":"Human readable name of this MCIO. See note 4.\n","type":"string"},"mcioNamespace":{"description":"Namespace of this MCIO.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cismId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioType":{"description":"The type of MCIO. Specific values, their semantics and associated MCIO types are defined in clause 5.5.4.9. Additional values are also permitted. See note 1.\n","type":"string","enum":["Deployment","StatefulSet","DaemonSet"]},"desiredInstances":{"description":"Number of desired MCIO instances.\n","type":"integer"},"availableInstances":{"description":"Number of available MCIO instances.\n","type":"integer"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"vnfPaasServiceInfo":{"description":"Information on the PaaS Services assigned and used by the VNF instance.\n","type":"array","items":{"description":"This type provides information about a PaaS Service that is used by a VNF instance. The PaasServiceInfo is comprised of various sets of information. Some information comes from the VNFD, other information comes from the PaaS Service assets provided by the NFVO to the VNFM, and other information is provided at runtime information about the usage of the PaaS Service.\n","type":"object","required":["id","paasServiceId","paasServiceType","paasServiceRequestId","paasServiceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceType":{"description":"The type of PaaS Service. The value of this attribute is expected to be matched against values of the registered PaaS Services in the PSR.\n","type":"string"},"paasServiceVersion":{"description":"A version.\n","type":"string"},"paasServiceRequestId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"paasServiceHandle":{"description":"This type provides information enabling the access and use of the PaaS Service by the VNF instance. The type and format of the handle depends on the form that the PaaS Service is formed.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"indicators":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"instantiate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"terminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"heal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"operate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"createSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"revertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeCurrentVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"recentVnfLcmOperationLinks":{"description":"Links to the most recent LCM operation occurrences related to this resource. See note 9.\n","type":"object","properties":{"recentVnfLcmOperation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmInstantiation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmTerminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmHeal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmOperate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmModifyInfo":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmCreateSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmRevertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmSelectDplMods":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}},"vnfcSnapshots":{"description":"Information about VNFC snapshots constituting this VNF snapshot.\n","type":"array","items":{"description":"This type represents a VNFC snapshot. * NOTE 1:\tThe identifier of the compute snapshot resource is assigned during creation of a VNFC\n snapshot being returned from the VIM as output data in the response message of the individual\n resource operations. This attribute shall only be present for a VNFC snapshot that has been\n newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n NOTE 2:\tThe identifier of the storage snapshot resource is assigned during creation of a VNFC snapshot\n being returned from the VIM as output data in the response message of the individual resource\n operations. This attribute shall only be present for a VNFC snapshot with an associated storage\n resource and that has been newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n","type":"object","required":["id","vnfcInstanceId","creationStartedAt","vnfcResourceInfoId"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"creationStartedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"creationFinishedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfcResourceInfoId":{"description":"This type represents the information about a VNFC instance that is part of a VNF instance. * NOTE:\tThis allows to represent the error condition that a VNFC instance has lost its resources.\n","type":"object","required":["id","vduId","vnfcState"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcResourceInfoId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcState":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"computeSnapshotResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"storageSnapshotResources":{"description":"Mapping of the storage resources associated to the VNFC with the storage snapshot resources.\n","type":"object","required":["storageResourceId"],"properties":{"storageResourceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"storageSnapshotResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"takenFrom":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"IndividualVnfSnapshot.Get.200":{"description":"200 OK\nShall be returned when information about an individual VNF snapshot was read successfully.\nThe response body shall contain a representation of the individual VNF snapshot resource.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents an individual VNF snapshot resource.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfSnapshotPkgId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfSnapshot":{"description":"This type represents a VNF snapshot.\n","type":"object","required":["id","vnfInstanceId","triggeredAt","vnfdId","vnfInfo","vnfcSnapshots"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"creationStartedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"creationFinishedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstance":{"description":"This type represents a VNF instance. * NOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist\n between the previous and the newly referred VNF package, i.e. when the new VNFD is\n changed with respect to the previous VNFD in other aspects than merely referencing\n to other VNF software images. In order to avoid misalignment of the VnfInstance with\n the current VNF's on-boarded VNF package, the values of attributes in the VnfInstance\n that have corresponding attributes in the VNFD shall be kept in sync with the values in the VNFD.\n* NOTE 2:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 3:\tThese attributes are sometimes also referred to as configuration parameters\n applicable to a VNF. Some of these are set prior to instantiation and cannot be modified\n if the VNF is instantiated, some are set prior to instantiation (are part of initial configuration)\n and can be modified later, and others can be set only after instantiation.\n The applicability of certain configuration may depend on the VNF and the required operation of\n the VNF at a certain point in time.\n* NOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child\n attributes of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared\n in the VNFD with a defined initial value. The defined initial values can be declared in the VNFD,\n and/or, in case of \"metadata\", obtained from the \"CreateVnfRequest\" structure. Child attributes of\n \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that have no defined initial value shall\n not be created, in order to be consistent with the semantics of the JSON Merge Patch method\n (see IETF RFC 7396) that interprets null values as deletion request.\n* NOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case\n of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding\n to the same VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc\n and externally-managed multi-site VL instance (refer to clause 5.5.3.5).\n* NOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity,\n they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n* NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual extCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the VNF \n LCM operation explicitly indicates the scale level for the aspect.\n* NOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n","type":"object","required":["id","vnfdId","vnfProvider","vnfProductName","vnfSoftwareVersion","vnfdVersion","instantiationState","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceName":{"description":"Name of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfInstanceDescription":{"description":"Human-readable description of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"Provider of the VNF and the VNFD. The value is copied from the VNFD.\n","type":"string"},"vnfProductName":{"description":"Name to identify the VNF Product. The value is copied from the VNFD.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateInfo":{"description":"This type provides input information related to certificate and certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateConfigurationInfo":{"description":"This type provides input information related to certificate management.\n","type":"object","required":["securityPolicy"],"properties":{"certificateBaseProfile":{"description":"This type provides input information to override certificate base profile for certificate management\nNOTE : At least one overriding attributes shall be present, otherwise shall be absent.\n","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"type":"string","description":"Issuer of certificates. See note."},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to subject of certificate.\n* NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of certification target subject FQDN. See note.","type":"string"},"organization":{"description":"Information of certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of certification target subject Country. See note.","type":"string"},"state":{"description":"Information of certification target subject State. See note.","type":"string"},"locality":{"description":"Information of certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"type":"string","description":"Basic constraints of certificates. See note.\n"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [7],clause 7.1.19.4). See note","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}},"securityPolicy":{"description":"Information for security policy to be satisfied for certificate.\n","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"integer"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"integer"}}}},"delegationSupportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"cmfInfo":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["id","endPoint","supportedProtocol"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"endPoint":{"description":"End point of CMF instance.","type":"object","required":["ipAddress","link"],"properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocols":{"description":"Supported protocol by CMF instance.","type":"array","items":{"type":"string","enum":["CMP","CMPv2","EST","SCEP"]}},"certificateChain":{"description":"Certificate chain that this CMF provides.","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"certificateContents":{"description":"Information for contents of issued certificates. The information contained in this attribute may be updated over time during the VNF LCM, e.g. certificate(s) renewal.\n","type":"array","items":{"description":"This type provides input information related to certificate content.\n","type":"object","required":["id","certificateDescId","certificateType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certficateDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"certificateType":{"description":"Type of this certificate.","type":"string","enum":["VNFCI_CERT","VNFOAM_CERT"]},"supportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"version":{"description":"A version.\n","type":"string"},"serialNumber":{"description":"Serial number of this certificate.","type":"integer"},"signatureAlgorithm":{"description":"Algorithm of this certificate's signature.","type":"string"},"issuer":{"description":"Issuer of this certificate.","type":"string"},"notBefore":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"notAfter":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"subject":{"description":"Subject of this certificate.","type":"string"},"publicKeyAlgorithm":{"description":"Algorithm of this certificate's public key.","type":"string"},"publicKey":{"description":"Public key of this certificate.","type":"string"},"certificateExtensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"instantiationState":{"description":"The instantiation state of the VNF.\n","type":"string","enum":["NOT_INSTANTIATED","INSTANTIATED"]},"instantiatedVnfInfo":{"description":"Information specific to an instantiated VNF instance. This attribute shall be present if the instantiateState attribute value is INSTANTIATED.\n","type":"object","required":["flavourId","vnfState","extCpInfo"],"properties":{"flavourId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfState":{"description":"STARTED: The VNF instance is up and running. STOPPED: The VNF instance has been shut down.\n","type":"string","enum":["STARTED","STOPPED"]},"vnfPowerState":{"description":"This type represents information about the power state of a VNF instance.\n","type":"object","required":["powerProfileId","name"],"properties":{"powerProfileId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Name of the power profile as provided in the VNFD.\n","type":"string"},"powerConsumptionInfo":{"description":"This type represents information about estimated power consumption of the resources associated with the power profile, as provided in the VNFD.\n","type":"object","required":["minPowerConsumption","maxPowerConsumption","averagePowerConsumption"],"properties":{"minPowerConsumption":{"description":"Minimum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"maxPowerConsumption":{"description":"Maximum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"averagePowerConsumption":{"description":"Average power consumption of this power profile. Unit is KW/h.\n","type":"integer"}}}}},"scaleStatus":{"description":"Scale status of the VNF, one entry per aspect. Represents for every scaling aspect how \"big\" the VNF has been scaled w.r.t. that aspect. This attribute shall be present if the VNF supports scaling. See clause B.2 for an explanation of VNF scaling. For an aspect that has not been deployed because the related deployableModule has not been selected, it indicates the scale level that has been requested in the instantiation or in a scaling operation, or, if none has been requested in any of them, the scale level applicable to the aspect based on the default instantiation level. See note 8.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleLevel":{"description":"Indicates the scale level. The minimum value shall be 0 and the maximum value shall be <= maxScaleLevel as described in the VNFD.\n","type":"integer"}}}},"maxScaleLevels":{"description":"Maximum allowed scale levels of the VNF, one entry per aspect. This attribute shall be present if the VNF supports scaling.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleLevel":{"description":"Indicates the scale level. The minimum value shall be 0 and the maximum value shall be <= maxScaleLevel as described in the VNFD.\n","type":"integer"}}}},"selectedDeployableModule":{"description":"References a currently selected deployable module, as defined in the VNFD, that has already completed the instantiation of its VNFCs\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceCapacityDefinition":{"description":"Shows current values of VDU attributes related to resource capacity, if different to the default values from the VNFD, as indicated in the (one or more) request(s) of all completed VNF LCM operation(s) that contain this attribute. If an attribute value has been modified multiple times, only the last value is shown. The values indicated in this attribute are applicable to all VNFC instances based on the VDU to which the resourceCapacityDefinition is related.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes. The tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request. At most one tag can be included when the data type is used in a VNF LCM operation request. When the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced. VALUES •\tCOMPUTE •\tSTORAGE •\tOSCONTAINER","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute ‘type’ indicates OSCONTAINER and absent otherwise.","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource.See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resources_property in the VNFD that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["resourceTemplateId"]},{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD for this virtual compute descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"extCpInfo":{"description":"Information about the external CPs exposed by the VNF instance. When trunking is enabled, the list of entries includes both, external CPs corresponding to parent ports of a trunk, and external CPs associated to sub-ports of a trunk. See note 7.\n","type":"array","minItems":1,"items":{"description":"This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n","type":"object","required":["id","cpdId","cpConfigId","cpProtocolInfo"],"oneOf":[{"required":["associatedVnfcCpId"]},{"required":["associatedVipCpId"]},{"required":["associatedVnfVirtualLinkId"]}],"properties":{"id":{"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"},"cpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extLinkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"associatedVnfcCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVipCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVirtualCpId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"associatedVnfVirtualLinkId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 3 and 4. It shall be present if the external CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"certificateContentId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cpSecurityGroupInfo":{"description":"This type provides the list of active security group rules applied to an external CP instance. The type identifies which \"SecurityGroupRule\" specified in the VNFD are activated and the values of its attributes.\n","type":"object","required":["securityGroupRuleId","etherType","protocol","portRangeMin","portRangeMax"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"description":{"description":"Human readable description of the security group rule.\n","type":"string"},"etherType":{"description":"Indicates the protocol carried over the Ethernet layer. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"protocol":{"description":"Indicates the protocol carried over the IP layer. Permitted values: any protocol defined in the IANA protocol registry (refer to clause 9.10.1.2 ofd ETSI GS NFV-SOL 001 for further information).\n","type":"string"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule.\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule.\n","type":"integer"}}}}}},"vipCpInfo":{"description":"VIP CPs that are part of the VNF instance. Shall be present when that particular VIP CP of the VNFC instance is associated to an external CP of the VNF instance.\nMay be present otherwise.\n","type":"array","items":{"description":"This type provides information related to virtual IP CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["cpInstanceId","cpdId"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for layer 3. There may be one cpProtocolInfo for layer 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"associatedVnfcCpIds":{"description":"Identifiers of the VnfcCps that share the virtual IP address allocated to the VIP CP instance. See note.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualCpInfo":{"description":"Virtual CPs that are part of the VNF instance. Shall be present when a particular virtual CP is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","items":{"description":"This type provides information related to a virtual CP instance of a VNF.\n* NOTE 1: A consumer of the VNF LCM interface can learn the actual VNFC instances implementing the service accessible via the virtual CP instance by querying the \"vnfcResourceInfo\" from the \"InstantiatedVnfInfo\" \n and filtering by corresponding \"vduIds\" values.\n* NOTE 2: The information can be omitted because it is already available as part of the external CP information in the VnfExtCpInfo structure.\n","type":"object","required":["cpInstanceId","cpdId","resourceHandle","vduIds"],"properties":{"cpInstanceId":{"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"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for each layer protocol supported. This attribute may be omitted if the virtual CP is exposed as an external CP. See note 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vduIds":{"description":"Reference to the VDU(s) which implement the service accessible via the virtual CP instance. See note.\n","type":"array","minItems":1,"items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"additionalServiceInfo":{"description":"Additional service identification information of the virtual CP instance.\n","type":"array","items":{"description":"This type provides additional service information of the virtual CP instance used to expose properties of the virtual CP to NFV-MANO.\nNOTE: This attribute shall only be present if additional information is needed to identify the service termination within the VNF, such as for example a URL path information in an HTTP request required \n to allow a single virtual CP IP address to be used for several HTTP based services that use the \n same port number.\n","type":"object","required":["portInfo"],"properties":{"portInfo":{"description":"Service port numbers exposed by the virtual CP instance.\n","minItems":1,"type":"array","items":{"description":"This type describes the service identifying port properties exposed by the virtual CP instance.\n","type":"object","required":["name","port","portConfigurable"],"properties":{"name":{"description":"The name of the port exposed by the virtual CP instance.\n","type":"string"},"protocol":{"description":"The L4 protocol for this port exposed by the virtual CP instance.\nPermitted values: - TCP - UDP - SCTP\n","type":"string","enum":["TCP","UDP","SCTP"]},"port":{"description":"The L4 port number exposed by the virtual CP instance.\n","type":"integer"},"portConfigurable":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"}}}},"serviceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"extVirtualLinkInfo":{"description":"Information about the external VLs the VNF instance is connected to.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD. The key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO. The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5 and 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored.\n\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for \n Kubernetes® that supports configuration of address pools for load balancer services.\n\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"string"},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"string"}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"routingResource":{"description":"Network resources that provide the forwarding/routing capabilities associated to the network resource realizing this VL.\n","type":"array","items":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}}},"extManagedVirtualLinkInfo":{"description":"Information about the externally managed internal VLs of the VNF instance. See note 5 and note 6. It is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed multi-site VL instance (refer to clause 5.5.3.5). Even though externally-managed internal VLs are also used for VNF-internal connectivity, they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n","type":"array","items":{"description":"This type provides information about an externally-managed virtual link. *NOTE: Both vnfLinkPort and vnfNetAttDefResource can be present in an ExtManagedVirtualLinkInfo to indicate that a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPorts":{"description":"Link ports of this VL.See note.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"vnfNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"routingResource":{"description":"Network resources that provide the forwarding/routing capabilities associated to the network resource realizing this VL.\n","type":"array","items":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}}},"monitoringParameters":{"description":"Active monitoring parameters.\n","type":"array","items":{"type":"object","required":["id","performanceMetric"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human readable name of the monitoring parameter, as defined in the VNFD.\n","type":"string"},"performanceMetric":{"description":"Performance metric that is monitored. This attribute shall contain the related \"Measurement Name\" value as defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"}}}},"localizationLanguage":{"description":"Information about localization language of the VNF (includes e.g. strings in the VNFD). The localization languages supported by a VNF can be declared in the VNFD, and localization language selection can take place at instantiation time. The value shall comply with the format defined in IETF RFC 5646.\n","type":"string"},"vnfcResourceInfo":{"description":"Information about the virtualised compute and storage resources used by the VNFCs of the VNF instance.\n","type":"array","items":{"description":"This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure \n of information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n - For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n - For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\n\n* NOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an internal VL that\n exposes an external CP. A VNFC CP is \"exposed as\" an external CP if it is connected directly\n to an external VL.\n* NOTE 3:\tThe information can be omitted because it is already available as part of the external CP information. * NOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\" structure by \n an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVnfc\"\n structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to \n this LCM operation occurrence.\n* NOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment \n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build \n a link redundant mated pair in SR-IOV cases.\n* NOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. * NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n","type":"object","required":["id","vduId","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"storageResourceIds":{"description":"References to the VirtualStorage resources or references to Storage MCIO(s). The value refers to a VirtualStorageResourceInfo item in the VnfInstance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcCpInfo":{"description":"All the CPs of the VNFC instance. See note 7.\n","type":"array","items":{"type":"object","required":["id","cpdId"],"properties":{"id":{"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"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP. May be omitted if the VNFC CP is exposed as an external CP. The information can be omitted because it is already available as part of the external CP information. See note 3.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"parentCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 5 and 6. It shall be present if the internal CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfVirtualLinkResourceInfo":{"description":"Information about the virtualised network resources used by the VLs of the VNF instance. See note 6. Even though externally-managed internal VLs are also used for VNF-internal connectivity, they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by an internal VL instance in a VNF instance. NOTE: If only the value or the presence of this attribute is changed in the \"VnfVirtualLinkResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a \n related \"AffectedVirtualLink\" structure in the VNF LCM operation occurrence notifications or the \n \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource","vnfLinkPorts"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLinkPorts":{"description":"Links ports of this VL. Shall be present when the linkPort is used for external connectivity by the VNF (refer to VnfLinkPortInfo). May be present otherwise.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualStorageResourceInfo":{"description":"Information on the virtualised storage resource(s) used as storage for the VNF instance.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance.\nNOTE: If only the value or the presence of this attribute is changed in the \"VirtualStorageResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVirtualStorage\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","virtualStorageDescId","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"vnfcInfo":{"description":"Information about the VNFC instances.\n","type":"array","items":{"description":"This type represents the information about a VNFC instance that is part of a VNF instance. * NOTE:\tThis allows to represent the error condition that a VNFC instance has lost its resources.\n","type":"object","required":["id","vduId","vnfcState"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcResourceInfoId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcState":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mcioInfo":{"description":"Information on the MCIO(s) representing VNFC instance(s) realized by one or a set of OS containers and created from the same VDU for the VNF instance.\n","type":"array","items":{"description":"This type provides information about an MCIO representing the set of VNFC instances realized by one or a set of OS containers which have been created based on the same VDU. Within the CISM, an MCIO controller monitors the actual state of an MCIO representing the set of VNFC instances realized by one or a set of OS containers and compare it to the desired state. For an MCIO related to a VDU that has the attribute \"isNumOfInstancesClusterBased\" set to FALSE the desired state is specified in the respective declarative descriptor. For an MCIO related to a VDU that has the attribute \"isNumOfInstancesClusterBased\" set to TRUE, the desired state is determined by the number of CIS-nodes in the cluster that fulfil the VDU requirements. It triggers actions toward the CIS to align the actual to the desired state. Monitoring the actual state includes monitoring the number of MCIO instances available at any specific point in time. In addition, an MCIO controller maintains properties and runtime information on the MCIO instances which have been created based on the same VDU. The McioInfo data structure provides the runtime information on the MCIOs obtained from the MCIO controller.\nNOTE: There are different types of MCIOs. The set of VNFC instances based on the same VDU is represented by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type \n of MCIO, e.g. a POD.\n\nRuntime information of the set of OS containers realizing an individual VNFC instance is not part of the McioInfo data structure; such runtime information is provided in the ResourceHandle data structure referenced from the VnfcResourceInfo. The McioInfo does not provide runtime information of a constituent VNFC instance created based on a specific VDU.\nNOTE 1: The type of MCIO as specified in the declarative descriptor of the MCIO, and that can be read from the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the \n “kind” property of the declarative descriptor.\nNOTE 2: If the attribute additionalInfo is present, it may contain runtime information on the actual and desired state of the MCIO(s). \nNOTE 3: When the container infrastructure service is a Kubernetes® instance, the mcioId is the combined values from the kind and name fields of the Kubernetes resource object, separated by a slash. \n Example: \"Deployment/abcd\". \nNOTE 4: When the container infrastructure service is a Kubernetes® instance, the mcioName is the name field of the resource object.\n","type":"object","required":["mcioId","mcioName","mcioNamespace","vduId","cismId","mcioType","desiredInstances","availableInstances"],"properties":{"mcioId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioName":{"description":"Human readable name of this MCIO. See note 4.\n","type":"string"},"mcioNamespace":{"description":"Namespace of this MCIO.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cismId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioType":{"description":"The type of MCIO. Specific values, their semantics and associated MCIO types are defined in clause 5.5.4.9. Additional values are also permitted. See note 1.\n","type":"string","enum":["Deployment","StatefulSet","DaemonSet"]},"desiredInstances":{"description":"Number of desired MCIO instances.\n","type":"integer"},"availableInstances":{"description":"Number of available MCIO instances.\n","type":"integer"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"vnfPaasServiceInfo":{"description":"Information on the PaaS Services assigned and used by the VNF instance.\n","type":"array","items":{"description":"This type provides information about a PaaS Service that is used by a VNF instance. The PaasServiceInfo is comprised of various sets of information. Some information comes from the VNFD, other information comes from the PaaS Service assets provided by the NFVO to the VNFM, and other information is provided at runtime information about the usage of the PaaS Service.\n","type":"object","required":["id","paasServiceId","paasServiceType","paasServiceRequestId","paasServiceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceType":{"description":"The type of PaaS Service. The value of this attribute is expected to be matched against values of the registered PaaS Services in the PSR.\n","type":"string"},"paasServiceVersion":{"description":"A version.\n","type":"string"},"paasServiceRequestId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"paasServiceHandle":{"description":"This type provides information enabling the access and use of the PaaS Service by the VNF instance. The type and format of the handle depends on the form that the PaaS Service is formed.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"indicators":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"instantiate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"terminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"heal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"operate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"createSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"revertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeCurrentVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"recentVnfLcmOperationLinks":{"description":"Links to the most recent LCM operation occurrences related to this resource. See note 9.\n","type":"object","properties":{"recentVnfLcmOperation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmInstantiation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmTerminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmHeal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmOperate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmModifyInfo":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmCreateSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmRevertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmSelectDplMods":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}},"vnfcSnapshots":{"description":"Information about VNFC snapshots constituting this VNF snapshot.\n","type":"array","items":{"description":"This type represents a VNFC snapshot. * NOTE 1:\tThe identifier of the compute snapshot resource is assigned during creation of a VNFC\n snapshot being returned from the VIM as output data in the response message of the individual\n resource operations. This attribute shall only be present for a VNFC snapshot that has been\n newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n NOTE 2:\tThe identifier of the storage snapshot resource is assigned during creation of a VNFC snapshot\n being returned from the VIM as output data in the response message of the individual resource\n operations. This attribute shall only be present for a VNFC snapshot with an associated storage\n resource and that has been newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n","type":"object","required":["id","vnfcInstanceId","creationStartedAt","vnfcResourceInfoId"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"creationStartedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"creationFinishedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfcResourceInfoId":{"description":"This type represents the information about a VNFC instance that is part of a VNF instance. * NOTE:\tThis allows to represent the error condition that a VNFC instance has lost its resources.\n","type":"object","required":["id","vduId","vnfcState"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcResourceInfoId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcState":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"computeSnapshotResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"storageSnapshotResources":{"description":"Mapping of the storage resources associated to the VNFC with the storage snapshot resources.\n","type":"object","required":["storageResourceId"],"properties":{"storageResourceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"storageSnapshotResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"takenFrom":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualVnfSnapshot.Delete.204":{"description":"204 NO CONTENT\nThe \"Individual subscription\" resource has been deleted successfully. The response body shall be empty.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{}},"IndividualVnfSnapshot.Delete.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the VNF\ninstance resource is in NOT_INSTANTIATED\nstate, or that another lifecycle management\noperation is ongoing.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall\nconvey more information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"Selectdeployablemodules.Post.202":{"description":"202 ACCEPTED\n\nShall be returned when the request has been accepted for processing.\nThe response body shall be empty.\nThe HTTP response shall include a \"Location\" HTTP header that contains the URI of the newly-created\n\"Individual VNF LCM operation occurrence\" resource corresponding to the operation.\n","headers":{"Location":{"description":"The resource URI of the created \"Individual VNF LCM operation\noccurrence\" resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided\nauthorization, or error details if the corresponding HTTP request\nhas provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}}}}} diff --git a/v5.3.1/SOL002-VNFLifecycleManagement-API.yaml b/v5.3.1/SOL002-VNFLifecycleManagement-API.yaml new file mode 100644 index 00000000..0c1a4bac --- /dev/null +++ b/v5.3.1/SOL002-VNFLifecycleManagement-API.yaml @@ -0,0 +1,88774 @@ +openapi: 3.0.2 +info: + title: SOL002 - VNF Lifecycle Management interface + description: | + SOL002 - VNF Lifecycle Management interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '2.16.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 002 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/05.03.01_60/gs_NFV-SOL002v050301p.pdf +servers: + - url: 'http://127.0.0.1/vnflcm/v2' + - url: 'https://127.0.0.1/vnflcm/v2' +paths: + /api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /vnf_instances: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The GET method queries information about multiple VNF instances. See + clause 5.4.2.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - $ref: '#/components/parameters/filter_vnf_instances' + - name: all_fields + description: > + Include all complex attributes in the response. See clause 5.3 of + ETSI GS NFV-SOL 013 [6] for details. The VNFM shall support this + parameter. + in: query + required: false + schema: + type: string + - name: fields + description: > + Complex attributes to be included into the response. See clause 5.3 + of ETSI GS NFV-SOL 013 [6] for details. The VNFM should support this + parameter. + in: query + required: false + schema: + type: string + - name: exclude_fields + description: > + Complex attributes to be excluded from the response. See clause 5.3 + of ETSI GS NFV-SOL 013 [6] for details. The VNFM should support this + parameter. + in: query + required: false + schema: + type: string + - $ref: '#/components/parameters/exclude_default_vnf_instances' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [6] for this + resource. + in: query + required: false + schema: + type: string + responses: + '200': + $ref: '#/components/responses/VnfInstances.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + The POST method creates a new VNF instance resource based on a VNF + package that is onboarded and in "ENABLED" state. + + See clause 5.4.2.3.1. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/VnfInstanceCreationRequest' + responses: + '201': + $ref: '#/components/responses/VnfInstances.Post.201' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/VnfInstances.Post.422' + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + Information about a VNF instance by reading an "Individual VNF + instance". See clause 5.4.3.3.2. + responses: + '200': + $ref: '#/components/responses/IndividualVnfInstance.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method deletes an "Individual VNF instance" resource. See clause + 5.4.3.3.5. + responses: + '204': + $ref: '#/components/responses/IndividualVnfInstance.Delete.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/IndividualVnfInstance.Delete.409' + '422': + description: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method modifies an "Individual VNF instance" resource. See clause + 5.4.3.3.4. + parameters: + - name: If-Unmodified-Since + description: > + Used to make the request method conditional on the selected + resource representation's last modification date being earlier than + or equal to the date provided in the field-value. If the condition + is not met, the request fails with a "412 Precondition Failed" + response. + required: false + in: header + schema: + type: string + format: date-time + - name: If-Match + description: > + Used to make the request method conditional on the recipient origin + server either having at least one current representation of the + target resource, when the field-value is "*", or having a current + representation of the target resource that has an entity-tag + matching a member of the list of entity-tags provided in the + field-value. If the condition is not met, the request fails with a + "412 Precondition Failed" response. + required: false + in: header + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/VnfInstanceModificationRequest' + responses: + '202': + $ref: '#/components/responses/IndividualVnfInstance.Patch.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/IndividualVnfInstance.Patch.409' + '412': + description: > + 412 PRECONDITION FAILED + + Error: A precondition given in an HTTP request header is not + fulfilled. Typically, this is due to an ETag mismatch, indicating + that the resource was modified by another entity. The response body + should contain a ProblemDetails structure, in which the "detail" + attribute should convey more information about the error. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/select_depl_mods': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + post: + description: > + The POST method requests to select deployable modules of a VNF instance. + See clause 5.4.11b.3.1 + requestBody: + $ref: '#/components/requestBodies/SelectVnfDeployableModulesRequest' + responses: + '202': + $ref: '#/components/responses/Selectdeployablemodules.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 409 CONFLICT + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/instantiate': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + post: + description: | + The POST method instantiates a VNF instance. See clause 5.4.4.3.1. + requestBody: + $ref: '#/components/requestBodies/VnfInstanceInstantiationRequest' + responses: + '202': + $ref: '#/components/responses/InstantiateVnfInstance.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/InstantiateVnfInstance.Post.409' + '422': + description: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/scale': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + post: + description: > + The POST method requests to scale a VNF instance resource incrementally. + See clause 5.4.5.3.1. + requestBody: + $ref: '#/components/requestBodies/VnfInstanceScaleRequest' + responses: + '202': + $ref: '#/components/responses/ScaleVnfInstance.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/ScaleVnfInstance.Post.409' + '422': + description: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/scale_to_level': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + post: + description: > + The POST method requests to scale a VNF instance resource to a target + level. See clause 5.4.6.3.1. + requestBody: + $ref: '#/components/requestBodies/VnfInstanceScaleToLevelRequest' + responses: + '202': + $ref: '#/components/responses/ScaleVnfInstanceToLevel.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/ScaleVnfInstanceToLevel.Post.409' + '422': + description: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/change_flavour': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + post: + description: > + The POST method changes the deployment flavour of a VNF instance. See + clause 5.4.7.3.1. + requestBody: + $ref: '#/components/requestBodies/VnfInstanceChangeFlavourRequest' + responses: + '202': + $ref: '#/components/responses/VnfInstanceChangeFlavour.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/VnfInstanceChangeFlavour.Post.409' + '422': + description: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/terminate': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + post: + description: > + The POST method triggers the VNFM to terminate a VNF instance and to + request to the VIM the release of its + + used virtualised resources. See clause 5.4.8.3.1. + requestBody: + $ref: '#/components/requestBodies/VnfInstanceTerminationRequest' + responses: + '202': + $ref: '#/components/responses/TerminateVnfInstance.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/TerminateVnfInstance.Post.409' + '422': + description: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/heal': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + post: + description: | + The POST method requests to heal a VNF instance. See clause 5.4.9.3.1. + requestBody: + $ref: '#/components/requestBodies/VnfInstanceHealRequest' + responses: + '202': + $ref: '#/components/responses/HealVnfInstance.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/HealVnfInstance.Post.409' + '422': + description: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/operate': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + post: + description: > + The POST method changes the operational state of a VNF instance. See + clause 5.4.10.3.1. + requestBody: + $ref: '#/components/requestBodies/VnfInstanceOperateRequest' + responses: + '202': + $ref: '#/components/responses/OperateVnfInstance.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/OperateVnfInstance.Post.409' + '422': + description: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/change_ext_conn': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + post: + description: > + The POST method changes the external connectivity of a VNF instance. See + clause 5.4.11.3.1. + requestBody: + $ref: '#/components/requestBodies/VnfInstanceChangeExtConnRequest' + responses: + '202': + $ref: '#/components/responses/VnfInstanceChangeExtConn.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/VnfInstanceChangeExtConn.Post.409' + '422': + description: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/change_vnfpkg': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + post: + description: > + The POST method changes the current VNF package on which the VNF + instance is based. + + See clause 5.4.11a.3.1. + requestBody: + $ref: '#/components/requestBodies/VnfInstanceChangeVnfPkgRequest' + responses: + '202': + $ref: '#/components/responses/VnfInstanceChangeVnfPkg.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/VnfInstanceChangeVnfPkg.Post.409' + '422': + description: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /vnf_lcm_op_occs: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The client can use this method to query status information about + multiple VNF lifecycle + + management operation occurrences. See clause 5.4.12.3.2. + parameters: + - $ref: '#/components/parameters/filter_vnf_lcm_op_occs' + - name: all_fields + description: > + Include all complex attributes in the response. See clause 5.3 of + ETSI GS NFV-SOL 013 [6] for details. The VNFM shall support this + parameter. + in: query + required: false + schema: + type: string + - name: fields + description: > + Complex attributes to be included into the response. See clause 5.3 + of ETSI GS NFV-SOL 013 [6] for details. The VNFM should support this + parameter. + in: query + required: false + schema: + type: string + - name: exclude_fields + description: > + Complex attributes to be excluded from the response. See clause 5.3 + of ETSI GS NFV-SOL 013 [6] for details. The VNFM should support this + parameter. + in: query + required: false + schema: + type: string + - $ref: '#/components/parameters/exclude_default_vnf_lcm_op_occs' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [6] for this + resource. + in: query + required: false + schema: + type: string + responses: + '200': + $ref: '#/components/responses/VnfLcmOpOccs.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_lcm_op_occs/{vnfLcmOpOccId}': + parameters: + - $ref: '#/components/parameters/VnfLcmOpOccId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The client can use this method to retrieve status information about a + VNF lifecycle management operation occurrence + + by reading an "Individual VNF LCM operation occurrence" resource. See + clause 5.4.13.3.2. + responses: + '200': + $ref: '#/components/responses/IndividualVnfLcmOpOcc.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_lcm_op_occs/{vnfLcmOpOccId}/retry': + parameters: + - $ref: '#/components/parameters/VnfLcmOpOccId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + post: + description: > + The POST method initiates retrying a VNF lifecycle operation if that + operation has experienced a temporary + + failure, i.e. the related "Individual VNF LCM operation occurrence" + resource is in "FAILED_TEMP" state. + + See clause 5.4.14.3.1. + responses: + '202': + $ref: '#/components/responses/VnfLcmOpOccRetry.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/VnfLcmOpOccRetry.Post.409' + '422': + description: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_lcm_op_occs/{vnfLcmOpOccId}/rollback': + parameters: + - $ref: '#/components/parameters/VnfLcmOpOccId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + post: + description: > + The POST method initiates rolling back a VNF lifecycle operation if that + operation has experienced a temporary + + failure, i.e. the related "Individual VNF LCM operation occurrence" + resource is in "FAILED_TEMP" state. + + See clause 5.4.15.3.1. + responses: + '202': + $ref: '#/components/responses/VnfLcmOpOccRollback.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/VnfLcmOpOccRollback.Post.409' + '422': + description: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_lcm_op_occs/{vnfLcmOpOccId}/fail': + parameters: + - $ref: '#/components/parameters/VnfLcmOpOccId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + post: + description: > + The POST method marks a VNF lifecycle management operation occurrence as + "finally failed" if that operation + + occurrence is in "FAILED_TEMP" state. See clause 5.4.16.3.1. + responses: + '200': + $ref: '#/components/responses/VnfLcmOpOccFail.Post.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/VnfLcmOpOccFail.Post.409' + '422': + description: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_lcm_op_occs/{vnfLcmOpOccId}/cancel': + parameters: + - $ref: '#/components/parameters/VnfLcmOpOccId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + post: + description: > + The POST method initiates cancelling an ongoing VNF lifecycle operation + while it is being executed or rolled + + back, i.e. the related "Individual VNF LCM operation occurrence" is + either in "PROCESSING" or "ROLLING_BACK" state. + + See clause 5.4.17.3.1. + responses: + '202': + $ref: '#/components/responses/VnfLcmOpOccCancel.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/VnfLcmOpOccCancel.Post.409' + '422': + description: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /subscriptions: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The GET method queries the list of active subscriptions of the + functional block that invokes the method. It can + + be used e.g. for resynchronization after error situations. See clause + 5.4.18.3.2. + parameters: + - $ref: '#/components/parameters/filter_subscriptions' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [6] for this + resource. + in: query + required: false + schema: + type: string + responses: + '200': + $ref: '#/components/responses/Subscriptions.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: | + The POST method creates a new subscription. See clause 5.4.18.3.1. + requestBody: + $ref: '#/components/requestBodies/VnfLcmSubscriptionRequest' + responses: + '201': + $ref: '#/components/responses/Subscriptions.Post.201' + '303': + description: | + 303 See Other + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/Subscriptions.Post.422' + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/subscriptions/{subscriptionId}': + parameters: + - $ref: '#/components/parameters/SubscriptionId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The GET method retrieves information about a subscription by reading an + "Individual subscription" resource. + + See clause 5.4.19.3.2. + responses: + '200': + $ref: '#/components/responses/IndividualSubscription.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + The DELETE method terminates an individual subscription. See clause + 5.4.19.3.5. + responses: + '204': + $ref: '#/components/responses/IndividualSubscription.Delete.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/create_snapshot': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + post: + description: > + The POST method requests tacking a VNF instance snapshot and populating + a previously created VNF snapshot resource + + (refer to clause 5.4.23.3.1) with the snapshot content. See clause + 5.4.21.3.1. + requestBody: + $ref: '#/components/requestBodies/VnfInstanceCreateSnapshotRequest' + responses: + '202': + $ref: '#/components/responses/VnfInstanceCreateSnapshot.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/VnfInstanceCreateSnapshot.Post.404' + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/VnfInstanceCreateSnapshot.Post.409' + '422': + $ref: '#/components/responses/VnfInstanceCreateSnapshot.Post.422' + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/revert_to_snapshot': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + post: + description: > + The POST method requests reverting a VNF/VNFC instance to a VNF/VNFC + snapshot. See clause 5.4.22.3.1. + requestBody: + $ref: '#/components/requestBodies/VnfInstanceRevertToSnapshotRequest' + responses: + '202': + $ref: '#/components/responses/VnfInstanceRevertToSnapshot.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/VnfInstanceRevertToSnapshot.Post.409' + '422': + description: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /vnf_snapshots: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + post: + description: > + The POST method creates a new individual VNF snapshot resource. See + clause 5.4.23.3.1. + requestBody: + $ref: '#/components/requestBodies/VnfSnapshotsRequest' + responses: + '201': + $ref: '#/components/responses/VnfSnapshots.Post.201' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 409 CONFLICT + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + get: + description: > + The GET method queries information about multiple VNF/VNFC snapshots. + See clause 5.4.23.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - $ref: '#/components/parameters/filter_vnf_snapshots' + - name: all_fields + description: > + Include all complex attributes in the response. See clause 5.3 of + ETSI GS NFV-SOL 013 [6] for details. The VNFM shall support this + parameter. + in: query + required: false + schema: + type: string + - name: fields + description: > + Complex attributes to be included into the response. See clause 5.3 + of ETSI GS NFV-SOL 013 [6] for details. The VNFM should support this + parameter. + in: query + required: false + schema: + type: string + - name: exclude_fields + description: > + Complex attributes to be excluded from the response. See clause 5.3 + of ETSI GS NFV-SOL 013 [6] for details. The VNFM should support this + parameter. + in: query + required: false + schema: + type: string + - $ref: '#/components/parameters/exclude_default_vnf_snapshots' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [6] for this + resource. + in: query + required: false + schema: + type: string + responses: + '200': + $ref: '#/components/responses/VnfSnapshots.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_snapshots/{vnfSnapshotInfoId}': + parameters: + - $ref: '#/components/parameters/VnfSnapshotInfoId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The GET method retrieves information about a VNF /VNFC snapshot by + reading an individual VNF snapshot resource. + + See clause 5.4.24.3.2. + responses: + '200': + $ref: '#/components/responses/IndividualVnfSnapshot.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method deletes an individual VNF snapshot resource and the + associated VNF snapshot information managed by + + the VNFM, and any resource associated to the VNF/VNFC snapshot managed + by the VIM. See clause 5.4.24.3.5. + responses: + '204': + $ref: '#/components/responses/IndividualVnfSnapshot.Delete.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/IndividualVnfSnapshot.Delete.409' + '422': + description: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + parameters: + filter_vnf_snapshots: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013. The VNFM shall support receiving this parameter as part of + the URI query string. The EM may supply this parameter. All attribute + names that appear in the VnfSnapshot and in data types referenced from + it shall be supported by the VNFM in the filter expression. + in: query + required: false + schema: + type: string + exclude_default_vnf_snapshots: + name: exclude_default + in: query + description: >- + Indicates to exclude the following complex attributes from the response. + See clause 5.3 of ETSI GS NFV-SOL 013 for details. The VNFM shall + support this parameter. The following attributes shall be excluded from + the VnfSnapshot structure in the response body if this parameter is + provided, or none of the parameters "all_fields," "fields", + "exclude_fields", "exclude_default" are provided: + - vnfInstance + - vnfcSnapshots + required: false + schema: + type: string + filter_subscriptions: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013. The VNFM shall support receiving this parameter as part of + the URI query string. The EM may supply this parameter. All attribute + names that appear in the LccnSubscription and in data types referenced + from it shall be supported by the VNFM in the filter expression. + in: query + required: false + schema: + type: string + filter_vnf_lcm_op_occs: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013. The VNFM shall support receiving this parameter as part of + the URI query string. The EM/VNF may supply this parameter. All + attribute names that appear in the VnfLcmOpOcc and in data types + referenced from it shall be supported by the VNFM in the filter + expression. + in: query + required: false + schema: + type: string + exclude_default_vnf_lcm_op_occs: + name: exclude_default + in: query + description: > + Indicates to exclude the following complex attributes from the response. + See clause 5.3 of ETSI GS NFV-SOL 013 for details. The VNFM shall + support this parameter. The following attributes shall be excluded from + the VnfLcmOpOcc structure in the response body if this parameter is + provided, or none of the parameters "all_fields", "fields", + "exclude_fields", "exclude_default" are provided: + - operationParams + - error + - resourceChanges + - changedInfo + - changedExtConnectivity + - lcmCoordinations + - modificationsTriggeredByVnfPkgChange + - warnings + required: false + schema: + type: string + filter_vnf_instances: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013. The VNFM shall support receiving this parameter as part of + the URI query string. The EM may supply this parameter. All attribute + names that appear in the VnfInstance and in data types referenced from + it shall be supported by the VNFM in the filter expression. + in: query + required: false + schema: + type: string + exclude_default_vnf_instances: + name: exclude_default + in: query + description: >- + Indicates to exclude the following complex attributes from the response. + See clause 5.3 of ETSI GS NFV-SOL 013 for details. The VNFM shall + support this parameter. The following attributes shall be excluded from + the VnfInstance structure in the response body if this parameter is + provided, or none of the parameters "all_fields", "fields", + "exclude_fields", "exclude_default" are provided: + - vnfConfigurableProperties + - instantiatedVnfInfo + - metadata + - extensions + required: false + schema: + type: string + VnfInstanceId: + name: vnfInstanceId + in: path + description: > + Identifier of the VNF instance. This identifier can be retrieved from + the resource referenced by the "Location" + + HTTP header in the response to a POST request creating a new VNF + instance resource. It can also be retrieved + + from the "id" attribute in the message content of that response. + required: true + style: simple + explode: false + schema: + type: string + VnfLcmOpOccId: + name: vnfLcmOpOccId + in: path + description: > + Identifier of a VNF lifecycle management operation occurrence. This + identifier can be retrieved from the resource + + referenced by the "Location" HTTP header in the response to a PATCH or + POST request triggering a VNF LCM operation. + + It can also be retrieved from the "vnfLcmOpOccId" attribute in the + VnfLcmOperationOccurrenceNotification. + required: true + style: simple + explode: false + schema: + type: string + SubscriptionId: + name: subscriptionId + in: path + description: > + Identifier of this subscription. This identifier can be retrieved from + the resource referenced by the "Location" + + HTTP header in the response to a POST request creating a new + subscription resource. It can also be retrieved from + + the "id" attribute in the message content of that response. + required: true + style: simple + explode: false + schema: + type: string + VnfSnapshotInfoId: + name: vnfSnapshotInfoId + in: path + description: > + Identifier of the individual VNF snapshot resource. This identifier can + be retrieved from the resource referenced by the + + "Location" HTTP header in the response to a POST request creating a new + VNF snapshot resource. It can also be + + retrieved from the "id" attribute in the message content of that + response. + required: true + style: simple + explode: false + schema: + type: string + requestBodies: + VnfInstanceCreationRequest: + description: | + The VNF creation parameters, as defined in clause 5.5.2.3. + content: + application/json: + schema: + description: > + This type represents request parameters for the "Create VNF + identifier" operation. + type: object + required: + - vnfdId + properties: + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfInstanceName: + description: | + Human-readable name of the VNF instance to be created. + type: string + vnfInstanceDescription: + description: | + Human-readable description of the VNF instance to be created. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + certificateConfigurationData: + description: > + This type provides input information related to certificate + management. + type: object + required: + - securityPolicy + properties: + overridingCertificateProfile: + description: > + Overriding certificate profile. This overrides the + certificateBaseProfile provided in the VNFD, and the CA + and CMF can additionally override aspects of this + certificateBaseProfile at later point in the VNF lifecycle + if necessary to meet operator security policy. + type: array + items: + description: > + This type provides input information to override + certificate base profile for certificate management + + NOTE : At least one overriding attributes shall be + present, otherwise shall be absent. + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + issuer: + type: string + description: Issuer of certificates. See note. + issuerUniqueIdentifier: + description: > + An identifier with the intention of being globally + unique. + type: string + subject: + description: > + This type provides input information related to + subject of certificate. + + * NOTE: At least one overriding attributes shall be + present, otherwise shall be absent. + type: object + properties: + commonName: + description: >- + Information of certification target subject + FQDN. See note. + type: string + organization: + description: >- + Information of certification target subject + Organization. See note. + type: string + country: + description: >- + Information of certification target subject + Country. See note. + type: string + state: + description: >- + Information of certification target subject + State. See note. + type: string + locality: + description: >- + Information of certification target subject + Locality. See note. + type: string + emailAddress: + description: >- + Information of certification contact email + address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of being globally + unique. + type: string + basicConstraints: + type: string + description: | + Basic constraints of certificates. See note. + issuerAltName: + description: >- + Alternative name of issuer of certificates in this + NS. See note. + type: array + items: + type: string + subjectAltName: + description: >- + Alternative name of subject of certificates. Shall + be present when this certificate is used for + encrypted communication using IP address and + subjectAltName attribute of CertificateBaseProfile + in CertificateDesc of VNFD is empty (see ETSI GS + NFV-IFA 011 [7],clause 7.1.19.4). See note + type: array + items: + type: string + nameConstraints: + description: Name constraints of certificates. See note. + type: array + items: + type: string + securityPolicy: + description: | + Security policy to be satisfied for certificate. + type: array + items: + description: > + This type provides input information related to security + policy for certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + maxValidityPeriod: + description: Allowed max validity period for certificates. + type: integer + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: integer + cmfData: + description: > + This type provides input information related to CMF for + certificate management. + type: object + required: + - endPoint + - supportedProtocol + properties: + endPoint: + description: End point of CMF instance. + type: object + required: + - ipAddress + - link + properties: + 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 + link: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + supportedProtocol: + description: Supported protocols by CMF instance. + type: array + items: + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + required: true + VnfInstanceModificationRequest: + description: Input parameters for VNF info modification + content: + application/merge-patch+json: + schema: + description: > + This type represents attribute modifications for an "Individual + VNF instance" resource, i.e. modifications to a resource + representation based on the "VnfInstance" data type. The + attributes of "VnfInstance" that can be modified according to the + provisions in clause 5.5.2.2 are included in the + "VnfInfoModificationRequest" data type. + type: object + properties: + vnfInstanceName: + description: > + New value of the "vnfInstanceName" attribute in "VnfInstance", + or "null" to remove the attribute. + type: string + vnfInstanceDescription: + description: > + New value of the "vnfInstanceDescription" attribute in + "VnfInstance", or "null" to remove the attribute. + type: string + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + vnfcInfoModifications: + description: > + Modifications of certain entries in the "vnfcInfo" attribute + array in the "instantiatedVnfInfo" attribute of "VnfInstance" + to be used as "newList" as defined below this table. The + following provisions shall apply when modifying an attribute + that is an array of objects of type "VnfcInfo" by supplying an + array of objects of type "VnfcInfoModifications". Assumptions: + 1) "oldList" is the "VnfcInfo" array to be modified and + "newList" is the "VnfcInfoModifications" + 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 "id" attribute as the "newEntry"; a "newEntry" has no corresponding entry if no such "oldEntry" exists. + 4) In any array of "VnfcInfo" resp. "VnfcInfoModifications" + structures, the content of "id" is unique + (i.e. there are no two entries with the same content of "id"). + 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 content of "newEntry" as specified for + the data type of "newEntry (refer to clause 5.5.3.24 for the data type "VnfcInfoModifications"). + type: array + items: + description: "This type represents modifications of an entry in an array of \"VnfcInfo\" objects. * NOTE:\tThe attribute \"id\" in this data type represents the same identifier as the attribute\n \"vnfcInstanceId\" in other related data types in the present document. For reasons of backward\n compatibility, this misalignment is not corrected.\n" + type: object + required: + - id + - vnfcConfigurableProperties + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + vnfcConfigurableProperties: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + required: true + VnfInstanceInstantiationRequest: + description: Parameters for the VNF instantiation. + content: + application/json: + schema: + description: > + This type represents request parameters for the "Instantiate VNF" + operation. * NOTE 1: The indication of externally-managed internal + VLs is needed in case networks have been + pre-configured for use with certain VNFs, for instance to ensure that these networks have certain + properties such as security or acceleration features, or to address particular network topologies. + The present document assumes that externally-managed internal VLs are managed by the NFVO and + created towards the VIM. + NOTE 2: The target size for VNF instantiation may be specified in either instantiationLevelId or targetScaleLevelInfo, + but not both. If none of the two attributes (instantiationLevelId or targetScaleLevelInfo) are + present, the default instantiation level as declared in the VNFD shall be used. + NOTE 3: If targetScaleLevelInfo is specified, information provided in targetScaleLevelInfo shall be used for + instantiating scalable constituents of the VNF (e.g, VDUs/VLs). For scaling aspects not specified in + targetScaleLevelInfo or for the VNF constituents (e.g., VDUs/VLs) that are not scalable, the default + instantiation level as declared in the VNFD shall be used for instantiation. + NOTE 4: If the referenced instantiationLevel or the targetScaleLevelInfo contain information related to VNFCs that are + not going to be instantiated due to the selection of deployable modules, the information is stored in the VNFM + for later use and included in the instantiatedVnfInfo. If none of the attributes is present, the information from the + defaultInstantiationLevel related to those VNFCs is stored and included in the instantiatedVnfInfo. If, during the + lifecycle of the VNF, as a result of a change of the selected deployable modules any of those VNFCs is going to + be instantiated, the stored information determines the number of instances, unless the request that triggered + the change also contains information about the number of instances. + type: object + required: + - flavourId + properties: + flavourId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + instantiationLevelId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + targetScaleLevelInfo: + description: > + This attribute is applicable if VNF supports target scale + level instantiation. For each scaling aspect of the current + deployment flavour, the attribute specifies the scale level + of VNF constituents (e.g., VDU level) to be instantiated. See + notes 2 3, and 4. + type: array + items: + description: > + This type represents the scale level of a VNF instance + related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + scaleLevel: + description: > + Indicates the scale level. The minimum value shall be 0 + and the maximum value shall be <= maxScaleLevel as + described in the VNFD. + type: integer + extVirtualLinks: + description: > + Information about external VLs to connect the VNF to, + including configuration information for the CPs via which the + VNF instance can attach to this VL. The following applies to + the "ExtVirtualLinkData" information provided in this request: + Even if the VNF is not instantiated in fully scaled-out + state, the API consumer shall provide enough CP configuration + records to allow connecting the VNF instance, fully scaled out + in all scaling aspects, to the external VLs. + type: array + items: + description: "This type represents an external VL. * NOTE 1: The information about the VIM connection referenced by the VIM connection id is known to the VNFM. \n Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2:\t A link port is not needed for an external CP instance that exposes a CP in the following cases:\n 1) For a virtual IP CP directly exposed as an external CP:\n 1.1) No dedicated IP address is allocated as virtual IP address, as indicated in the VNFD.\n 1.2) A dedicated IP address is allocated as virtual IP address, but the NFVO indicates that no port is\n needed (createExtLinkPort in VnfExtCpconfig set to false).\n 2) For a virtual IP CP exposed as an external CP via a floating IP address:\n 2.1) No dedicated IP address is allocated as virtual IP address, as indicated in the VNFD, and the VNFC\n CP associated to the virtual IP CP is also exposed via a floating IP address.\n 3) For a VIRTUAL CP exposed as an external CP.\n 4) For a VNFC CP exposed as an external CP in a secondary container cluster external network.\n\n* NOTE 3: An example of the network attachment definition resource when the container infrastructure service\n management is a Kubernetes® instance is a network attachment definition (NAD).\n\n* NOTE 4: Either \"extCps\" or “extCpsDeletion\" shall be present, but not both.\n" + type: object + required: + - id + - resourceId + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + extCps: + description: > + External CPs of the VNF to be connected to this external + VL. Entries in the list of external CP data that are + unchanged need not be supplied if the ExtVirtualLinkData + structure is part of a request or response that modifies + the external connectivity.See note 4. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. The + entries shall be applied by the VNFM according to + the rules of JSON Merge Patch (see IETF RFC 7396). + See notes 2, 3, 4, 5 and 6. In case of deleting an + external CP, the list of instances to be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the + CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored. + + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + extLinkPorts: + description: > + Externally provided link ports to be used to connect + external connection points to this external VL. If this + attribute is not present, the VNFM shall create the link + ports on the external VL except in the cases defined + below. See note 2. + type: array + items: + description: "This type represents an externally provided link port to be used to connect an external connection point to an external VL. * NOTE:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + extNetAttDefResourceData: + description: > + Externally provided network attachment definition + resource(s) that provide the specification of the + interface to attach external CPs to this external VL. + See note 3. It is only applicable if the external VL is + realized by a secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + This type represents a network attachment definition + resource that provides the specification of the + interface to be used to connect one or multiple + connection points to a secondary container cluster + network realizing a VL. + type: object + required: + - netAttDefResourceId + - resourceHandle + properties: + netAttDefResourceId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + extCpsDeletion: + description: > + External CPs of the VNF to be disconnected from this + external VL and to be deleted. See note 4. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. The + entries shall be applied by the VNFM according to + the rules of JSON Merge Patch (see IETF RFC 7396). + See notes 2, 3, 4, 5 and 6. In case of deleting an + external CP, the list of instances to be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the + CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored. + + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + extManagedVirtualLinks: + description: > + Information about external VLs to connect the VNF to. See note + 1. + type: array + items: + description: "This type represents an externally-managed internal VL. * NOTE:\tThe information about the VIM connection referenced by the VIM connection id is known to the VNFM.\n Moreover, the identifier of the VIM connection provides scope to the resourceId.\n" + type: object + required: + - id + - virtualLinkDescId + - resourceId + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfVirtualLinkDescId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + localizationLanguage: + description: > + Localization language of the VNF to be instantiated. The value + shall comply with the format defined in IETF RFC 5646. + type: string + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + selectedDeployableModule: + description: > + Identifier of a selected deployable module. Only VNFCs based + on VDUs that belong to deployable modules listed in this + attribute are requested to be instantiated. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + resourceCapacityDefinition: + description: > + Indicates values for resource capacity related attributes + pertaining to a descriptor. Values can only be provided for + resource capacity related attributes that have been defined in + the VNFD as being configurable. Furthermore, provided values + shall be within the allowed values indicated in the VNFD. + type: array + items: + description: > + This type represents selected values for capacity related + VDU attributes. + + * NOTE: Resource definitions not related to a VDU are not + considered in this version of the present document. + type: object + required: + - type + properties: + tag: + description: >- + Tag assigned by the issuer of a VNF LCM operation + request that contains this data type with values to be + applied to a VDU. It is used for tracking purposes. The + tag is preserved in the run time record as long as at + least one value of the capacity related attributes + associated with that tag is still valid, i.e., it has + not been modified by a later VNF LCM operation request. + At most one tag can be included when the data type is + used in a VNF LCM operation request. When the data type + is used in the VnfInstance data type it may contain + multiple tags, namely those provided in VNF LCM + requests, if at least one of the values provided in that + request associated to that tag is still applicable in + the VNFCs created from this VDU, i.e., it has not been + modified by a later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: "Type of the resource definition referenced. VALUES •\tCOMPUTE •\tSTORAGE •\tOSCONTAINER" + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + osContainerDescData: + description: >- + Indicates values for resource capacity related + attributes in an OsContainerDesc. It shall be present + when the attribute ‘type’ indicates OSCONTAINER and + absent otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of an OsContainer resource. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for the + container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for the + container expressed in the same units as specified + in the requested_memory_resources_valid_values + property in VNFD for this container descriptor. + See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources of the + type indicated in the key. The key is a string + that identifies an extended resource indicated in + the extended_resource_requests property in the + VNFD for this container descriptor. The value is + an integer that indicates the required amount for + a particular extended resource.See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container can + maximally use in milli-CPU. See note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required for all the + hugepages of the size indicated in the key. The + key is a string and corresponds to one of the + values of the hugepage sizes indicated in the + huge_pages_resources property in the VNFD for + this container descriptor. The value is a number + that indicates the required total size expressed + in the same units as in the + huge_pages_resources_property in the VNFD that + indicates the valid values for required total size + for the particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores are + requested to be allocated to logical CPU cores + according to the cpuOperationalPowerStates + attribute. In case of "DYNAMIC", the CPU power + states of virtual CPU cores can be allocated + to logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual compute resource + of a VM. + + * NOTE: At least one of the attributes shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - resourceTemplateId + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required for all the + hugepages of the size indicated in the key. The key + is a string and corresponds to one of the values of + the hugepage sizes indicated in the + huge_pages_requirements property in the VNFD for + this virtual compute descriptor. The value is a + number that indicates the required total size + expressed in the same units as in the + huge_pages_requirements property in the VNFD that + indicates the valid values for required total size + for the particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores are + requested to be allocated to logical CPU cores + according to the cpuOperationalPowerStates + attribute. In case of "DYNAMIC", the CPU power + states of virtual CPU cores can be allocated to + logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size related + attribute in an VirtualStorageDesc. It shall be present + when the attribute 'type' indicates STORAGE and absent + otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual storage + resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + required: true + SelectVnfDeployableModulesRequest: + description: Parameters for the VNF deployable modules selection. + content: + application/json: + schema: + description: > + This type represents request parameters for the "Select VNF + deployable modules" operation. * NOTE 1: Thus, the select VNF + deployable modules operation cannot be used as a scale VNF + operation to + horizontally scale VNFCs that were already instantiated. + * NOTE 2: Thus, the select VNF deployable modules operation cannot + be used as a scale VNF operation to + vertically scale VNFCs that were already instantiated. + type: object + properties: + selectedDeployableModule: + description: > + Identifier of a selected deployable module, as defined in the + VNFD. VNFCs based on VDUs that belong to deployable modules + listed in this attribute will be instantiated if not already + instantiated. VNFCs based on VDUs that belong to deployable + modules not listed in this attribute and that were already + instantiated will be terminated. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + targetScaleLevelInfo: + description: > + Defines the target scale levels of scaling aspects of the VDUs + that belong to selected deployable modules. If this attribute + is not present or if there are VDUs that belong to selected + deployable modules that take no part in any of the scaling + aspects indicated in this attribute, the VNFCs based on those + VDUs shall be instantiated according to the currently valid + VNF scale level or instantiation level. This attribute should + only contain scale level information of scaling aspects + associated to VDUs that will be used to instantiate VNFCs as + a result of this operation. If it contains other scale level + information it shall be ignored. See note. The VNF Provider + defines in the VNFD whether or not a particular VNF supports + scaling according to this parameter. Such a property in the + VNFD applies for all instances of a particular VNF. + type: array + items: + description: > + This type represents the scale level of a VNF instance + related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + scaleLevel: + description: > + Indicates the scale level. The minimum value shall be 0 + and the maximum value shall be <= maxScaleLevel as + described in the VNFD. + type: integer + resourceCapacityDefinition: + description: > + Indicates values for resource capacity related attributes + pertaining to a descriptor. Values can only be provided for + resource capacity related attributes that have been defined in + the VNFD as being configurable. Furthermore, provided values + shall be within the allowed values indicated in the VNFD. This + attribute should only contain information about resource + capacity related attributes of VDUs that will be used to + instantiate VNFCs as a result of this operation. If it + contains information about attributes of other VDUs it shall + be ignored. See note 2. + type: array + items: + description: > + This type represents selected values for capacity related + VDU attributes. + + * NOTE: Resource definitions not related to a VDU are not + considered in this version of the present document. + type: object + required: + - type + properties: + tag: + description: >- + Tag assigned by the issuer of a VNF LCM operation + request that contains this data type with values to be + applied to a VDU. It is used for tracking purposes. The + tag is preserved in the run time record as long as at + least one value of the capacity related attributes + associated with that tag is still valid, i.e., it has + not been modified by a later VNF LCM operation request. + At most one tag can be included when the data type is + used in a VNF LCM operation request. When the data type + is used in the VnfInstance data type it may contain + multiple tags, namely those provided in VNF LCM + requests, if at least one of the values provided in that + request associated to that tag is still applicable in + the VNFCs created from this VDU, i.e., it has not been + modified by a later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: "Type of the resource definition referenced. VALUES •\tCOMPUTE •\tSTORAGE •\tOSCONTAINER" + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + osContainerDescData: + description: >- + Indicates values for resource capacity related + attributes in an OsContainerDesc. It shall be present + when the attribute ‘type’ indicates OSCONTAINER and + absent otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of an OsContainer resource. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for the + container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for the + container expressed in the same units as specified + in the requested_memory_resources_valid_values + property in VNFD for this container descriptor. + See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources of the + type indicated in the key. The key is a string + that identifies an extended resource indicated in + the extended_resource_requests property in the + VNFD for this container descriptor. The value is + an integer that indicates the required amount for + a particular extended resource.See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container can + maximally use in milli-CPU. See note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required for all the + hugepages of the size indicated in the key. The + key is a string and corresponds to one of the + values of the hugepage sizes indicated in the + huge_pages_resources property in the VNFD for + this container descriptor. The value is a number + that indicates the required total size expressed + in the same units as in the + huge_pages_resources_property in the VNFD that + indicates the valid values for required total size + for the particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores are + requested to be allocated to logical CPU cores + according to the cpuOperationalPowerStates + attribute. In case of "DYNAMIC", the CPU power + states of virtual CPU cores can be allocated + to logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual compute resource + of a VM. + + * NOTE: At least one of the attributes shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - resourceTemplateId + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required for all the + hugepages of the size indicated in the key. The key + is a string and corresponds to one of the values of + the hugepage sizes indicated in the + huge_pages_requirements property in the VNFD for + this virtual compute descriptor. The value is a + number that indicates the required total size + expressed in the same units as in the + huge_pages_requirements property in the VNFD that + indicates the valid values for required total size + for the particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores are + requested to be allocated to logical CPU cores + according to the cpuOperationalPowerStates + attribute. In case of "DYNAMIC", the CPU power + states of virtual CPU cores can be allocated to + logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size related + attribute in an VirtualStorageDesc. It shall be present + when the attribute 'type' indicates STORAGE and absent + otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual storage + resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + required: true + VnfInstanceScaleRequest: + description: Parameters for the scale VNF operation. + content: + application/json: + schema: + description: > + This type represents request parameters for the "Scale VNF" + operation. + type: object + required: + - type + properties: + type: + description: > + Indicates the type of the scale operation requested. Permitted + values: * SCALE_OUT: adding additional VNFC instances to the + VNF to increase + capacity + * SCALE_IN: removing VNFC instances from the VNF in order to + release + unused capacity. + * SCALE_VERTICAL: increasing or decreasing the resource + capacity of all + instances of one or multiple VNFCs. + type: string + enum: + - SCALE_OUT + - SCALE_IN + - SCALE_VERTICAL + aspectId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + numberOfSteps: + description: > + Number of scaling steps to be executed as part of this Scale + VNF operation. It shall be a positive number and the default + value shall be 1. + type: integer + default: 1 + resourceCapacityDefinition: + description: > + Indicates values for resource capacity related attributes + pertaining to a descriptor. The indicated values are absolute + (target) values, as opposed to relative (delta) values. Values + can only be provided for resource capacity related attributes + that have been defined in the VNFD as being configurable. + Furthermore, provided values shall be within the allowed + values indicated in the VNFD. It shall be present when ‘type’ + indicates SCALE_VERTICAL and absent otherwise. + type: array + items: + description: > + This type represents selected values for capacity related + VDU attributes. + + * NOTE: Resource definitions not related to a VDU are not + considered in this version of the present document. + type: object + required: + - type + properties: + tag: + description: >- + Tag assigned by the issuer of a VNF LCM operation + request that contains this data type with values to be + applied to a VDU. It is used for tracking purposes. The + tag is preserved in the run time record as long as at + least one value of the capacity related attributes + associated with that tag is still valid, i.e., it has + not been modified by a later VNF LCM operation request. + At most one tag can be included when the data type is + used in a VNF LCM operation request. When the data type + is used in the VnfInstance data type it may contain + multiple tags, namely those provided in VNF LCM + requests, if at least one of the values provided in that + request associated to that tag is still applicable in + the VNFCs created from this VDU, i.e., it has not been + modified by a later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: "Type of the resource definition referenced. VALUES •\tCOMPUTE •\tSTORAGE •\tOSCONTAINER" + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + osContainerDescData: + description: >- + Indicates values for resource capacity related + attributes in an OsContainerDesc. It shall be present + when the attribute ‘type’ indicates OSCONTAINER and + absent otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of an OsContainer resource. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for the + container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for the + container expressed in the same units as specified + in the requested_memory_resources_valid_values + property in VNFD for this container descriptor. + See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources of the + type indicated in the key. The key is a string + that identifies an extended resource indicated in + the extended_resource_requests property in the + VNFD for this container descriptor. The value is + an integer that indicates the required amount for + a particular extended resource.See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container can + maximally use in milli-CPU. See note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required for all the + hugepages of the size indicated in the key. The + key is a string and corresponds to one of the + values of the hugepage sizes indicated in the + huge_pages_resources property in the VNFD for + this container descriptor. The value is a number + that indicates the required total size expressed + in the same units as in the + huge_pages_resources_property in the VNFD that + indicates the valid values for required total size + for the particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores are + requested to be allocated to logical CPU cores + according to the cpuOperationalPowerStates + attribute. In case of "DYNAMIC", the CPU power + states of virtual CPU cores can be allocated + to logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual compute resource + of a VM. + + * NOTE: At least one of the attributes shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - resourceTemplateId + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required for all the + hugepages of the size indicated in the key. The key + is a string and corresponds to one of the values of + the hugepage sizes indicated in the + huge_pages_requirements property in the VNFD for + this virtual compute descriptor. The value is a + number that indicates the required total size + expressed in the same units as in the + huge_pages_requirements property in the VNFD that + indicates the valid values for required total size + for the particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores are + requested to be allocated to logical CPU cores + according to the cpuOperationalPowerStates + attribute. In case of "DYNAMIC", the CPU power + states of virtual CPU cores can be allocated to + logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size related + attribute in an VirtualStorageDesc. It shall be present + when the attribute 'type' indicates STORAGE and absent + otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual storage + resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + required: true + VnfInstanceScaleToLevelRequest: + description: Parameters for the scale VNF to Level operation. + content: + application/json: + schema: + description: "This type represents request parameters for the \"Scale VNF to Level\" operation.\nNOTE 1:\tEither the instantiationLevelId attribute or the scaleInfo attribute or the powerProfileId attribute shall \n be included, but not multiple of them.\nNOTE 2: If the referenced instantiationLevel, the scaleInfo or powerProfileId attribute contain information related to VNFCs\n that are not going to be instantiated due to the selection of deployable modules, the information is stored in the \n VNFM for later use and included in the instantiatedVnfInfo. If, during the lifecycle of the VNF, as a result of \n a change of the selected deployable modules any of those VNFCs is going to be instantiated, the stored information\n determines the number of instances, unless the request that triggered the change also contains information\n about the number of instances.\n" + type: object + anyOf: + - oneOf: + - required: + - instantiationLevelId + - required: + - scaleInfo + - required: + - powerProfileId + properties: + instantiationLevelId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + scaleInfo: + description: > + For each scaling aspect of the current deployment flavour, + indicates the target scale level to which the VNF is to be + scaled. See notes 1 and 2. + type: array + items: + description: > + This type represents the scale level of a VNF instance + related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + scaleLevel: + description: > + Indicates the scale level. The minimum value shall be 0 + and the maximum value shall be <= maxScaleLevel as + described in the VNFD. + type: integer + powerProfileId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + required: true + VnfInstanceChangeFlavourRequest: + description: Parameters for the Change VNF Flavour operation. + content: + application/json: + schema: + description: "This type represents request parameters for the \"Change VNF flavour\" operation. * NOTE 1:\tThe indication of externally-managed internal VLs is needed in case networks have been\n pre-configured for use with certain VNFs, for instance to ensure that these networks have certain\n properties such as security or acceleration features, or to address particular network topologies.\n The present document assumes that externally-managed internal VLs are managed by the NFVO and\n created towards the VIM.\n NOTE 2: The target size for VNF instantiation may be specified in either instantiationLevelId or \n targetScaleLevelInfo, but not both. If none of the two attributes (instantiationLevelId \n or targetScaleLevelInfo) are present, the default instantiation level as declared in the \n VNFD shall be used.\n NOTE 3: If targetScaleLevelInfo is specified, information provided in targetScaleLevelInfo shall \n be used for instantiating scalable constituents of the VNF (e.g, VDUs/VLs). For scaling \n aspects not specified in targetScaleLevelInfo or for the VNF constituents (e.g., VDUs/VLs) \n that are not scalable, the default instantiation level as declared in the VNFD shall be used \n for instantiation.\n" + type: object + required: + - newFlavourId + properties: + newFlavourId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + instantiationLevelId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + targetScaleLevelInfo: + description: > + This attribute is applicable if VNF supports target scale + level instantiation. For each scaling aspect of the current + deployment flavour, the attribute specifies the scale level + of VNF constituents (e.g., VDU level) to be instantiated. See + notes 2 and 3. + type: array + items: + description: > + This type represents the scale level of a VNF instance + related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + scaleLevel: + description: > + Indicates the scale level. The minimum value shall be 0 + and the maximum value shall be <= maxScaleLevel as + described in the VNFD. + type: integer + extVirtualLinks: + description: > + Information about external VLs to connect the VNF to, + including configuration information for the CPs via which the + VNF instance can attach to this VL. Entries in the list of + external VLs that are unchanged need not be supplied as part + of this request. The following applies to the + "ExtVirtualLinkData" information provided in this request, + together with the related "ExtVirtualLinkInfo" information + known to the VNFM represented in the "VnfInstance" structure + (see clause 5.5.2.2): Even if the VNF is not in fully + scaled-out state after changing the flavour, the API consumer + shall provide enough CP configuration records to allow + connecting the VNF instance, fully scaled out in all scaling + aspects, to the external VLs. + type: array + items: + description: "This type represents an external VL. * NOTE 1: The information about the VIM connection referenced by the VIM connection id is known to the VNFM. \n Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2:\t A link port is not needed for an external CP instance that exposes a CP in the following cases:\n 1) For a virtual IP CP directly exposed as an external CP:\n 1.1) No dedicated IP address is allocated as virtual IP address, as indicated in the VNFD.\n 1.2) A dedicated IP address is allocated as virtual IP address, but the NFVO indicates that no port is\n needed (createExtLinkPort in VnfExtCpconfig set to false).\n 2) For a virtual IP CP exposed as an external CP via a floating IP address:\n 2.1) No dedicated IP address is allocated as virtual IP address, as indicated in the VNFD, and the VNFC\n CP associated to the virtual IP CP is also exposed via a floating IP address.\n 3) For a VIRTUAL CP exposed as an external CP.\n 4) For a VNFC CP exposed as an external CP in a secondary container cluster external network.\n\n* NOTE 3: An example of the network attachment definition resource when the container infrastructure service\n management is a Kubernetes® instance is a network attachment definition (NAD).\n\n* NOTE 4: Either \"extCps\" or “extCpsDeletion\" shall be present, but not both.\n" + type: object + required: + - id + - resourceId + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + extCps: + description: > + External CPs of the VNF to be connected to this external + VL. Entries in the list of external CP data that are + unchanged need not be supplied if the ExtVirtualLinkData + structure is part of a request or response that modifies + the external connectivity.See note 4. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. The + entries shall be applied by the VNFM according to + the rules of JSON Merge Patch (see IETF RFC 7396). + See notes 2, 3, 4, 5 and 6. In case of deleting an + external CP, the list of instances to be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the + CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored. + + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + extLinkPorts: + description: > + Externally provided link ports to be used to connect + external connection points to this external VL. If this + attribute is not present, the VNFM shall create the link + ports on the external VL except in the cases defined + below. See note 2. + type: array + items: + description: "This type represents an externally provided link port to be used to connect an external connection point to an external VL. * NOTE:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + extNetAttDefResourceData: + description: > + Externally provided network attachment definition + resource(s) that provide the specification of the + interface to attach external CPs to this external VL. + See note 3. It is only applicable if the external VL is + realized by a secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + This type represents a network attachment definition + resource that provides the specification of the + interface to be used to connect one or multiple + connection points to a secondary container cluster + network realizing a VL. + type: object + required: + - netAttDefResourceId + - resourceHandle + properties: + netAttDefResourceId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + extCpsDeletion: + description: > + External CPs of the VNF to be disconnected from this + external VL and to be deleted. See note 4. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. The + entries shall be applied by the VNFM according to + the rules of JSON Merge Patch (see IETF RFC 7396). + See notes 2, 3, 4, 5 and 6. In case of deleting an + external CP, the list of instances to be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the + CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored. + + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + extManagedVirtualLinks: + description: > + Information about external VLs to connect the VNF to. See note + 1. + type: array + items: + description: "This type represents an externally-managed internal VL. * NOTE:\tThe information about the VIM connection referenced by the VIM connection id is known to the VNFM.\n Moreover, the identifier of the VIM connection provides scope to the resourceId.\n" + type: object + required: + - id + - virtualLinkDescId + - resourceId + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfVirtualLinkDescId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + selectedDeployableModule: + description: > + Identifier of a selected deployable module. Only VNFCs based + on VDUs that belong to deployable modules listed in this + attribute are requested to be instantiated. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + resourceCapacityDefinition: + description: > + Indicates values for resource capacity related attributes + pertaining to a descriptor. Values can only be provided for + resource capacity related attributes that have been defined in + the VNFD as being configurable. Furthermore, provided values + shall be within the allowed values indicated in the VNFD. + type: array + items: + description: > + This type represents selected values for capacity related + VDU attributes. + + * NOTE: Resource definitions not related to a VDU are not + considered in this version of the present document. + type: object + required: + - type + properties: + tag: + description: >- + Tag assigned by the issuer of a VNF LCM operation + request that contains this data type with values to be + applied to a VDU. It is used for tracking purposes. The + tag is preserved in the run time record as long as at + least one value of the capacity related attributes + associated with that tag is still valid, i.e., it has + not been modified by a later VNF LCM operation request. + At most one tag can be included when the data type is + used in a VNF LCM operation request. When the data type + is used in the VnfInstance data type it may contain + multiple tags, namely those provided in VNF LCM + requests, if at least one of the values provided in that + request associated to that tag is still applicable in + the VNFCs created from this VDU, i.e., it has not been + modified by a later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: "Type of the resource definition referenced. VALUES •\tCOMPUTE •\tSTORAGE •\tOSCONTAINER" + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + osContainerDescData: + description: >- + Indicates values for resource capacity related + attributes in an OsContainerDesc. It shall be present + when the attribute ‘type’ indicates OSCONTAINER and + absent otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of an OsContainer resource. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for the + container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for the + container expressed in the same units as specified + in the requested_memory_resources_valid_values + property in VNFD for this container descriptor. + See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources of the + type indicated in the key. The key is a string + that identifies an extended resource indicated in + the extended_resource_requests property in the + VNFD for this container descriptor. The value is + an integer that indicates the required amount for + a particular extended resource.See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container can + maximally use in milli-CPU. See note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required for all the + hugepages of the size indicated in the key. The + key is a string and corresponds to one of the + values of the hugepage sizes indicated in the + huge_pages_resources property in the VNFD for + this container descriptor. The value is a number + that indicates the required total size expressed + in the same units as in the + huge_pages_resources_property in the VNFD that + indicates the valid values for required total size + for the particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores are + requested to be allocated to logical CPU cores + according to the cpuOperationalPowerStates + attribute. In case of "DYNAMIC", the CPU power + states of virtual CPU cores can be allocated + to logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual compute resource + of a VM. + + * NOTE: At least one of the attributes shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - resourceTemplateId + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required for all the + hugepages of the size indicated in the key. The key + is a string and corresponds to one of the values of + the hugepage sizes indicated in the + huge_pages_requirements property in the VNFD for + this virtual compute descriptor. The value is a + number that indicates the required total size + expressed in the same units as in the + huge_pages_requirements property in the VNFD that + indicates the valid values for required total size + for the particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores are + requested to be allocated to logical CPU cores + according to the cpuOperationalPowerStates + attribute. In case of "DYNAMIC", the CPU power + states of virtual CPU cores can be allocated to + logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size related + attribute in an VirtualStorageDesc. It shall be present + when the attribute 'type' indicates STORAGE and absent + otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual storage + resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + certificateConfigurationData: + description: > + This type provides input information related to certificate + management. + type: object + required: + - securityPolicy + properties: + overridingCertificateProfile: + description: > + Overriding certificate profile. This overrides the + certificateBaseProfile provided in the VNFD, and the CA + and CMF can additionally override aspects of this + certificateBaseProfile at later point in the VNF lifecycle + if necessary to meet operator security policy. + type: array + items: + description: > + This type provides input information to override + certificate base profile for certificate management + + NOTE : At least one overriding attributes shall be + present, otherwise shall be absent. + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + issuer: + type: string + description: Issuer of certificates. See note. + issuerUniqueIdentifier: + description: > + An identifier with the intention of being globally + unique. + type: string + subject: + description: > + This type provides input information related to + subject of certificate. + + * NOTE: At least one overriding attributes shall be + present, otherwise shall be absent. + type: object + properties: + commonName: + description: >- + Information of certification target subject + FQDN. See note. + type: string + organization: + description: >- + Information of certification target subject + Organization. See note. + type: string + country: + description: >- + Information of certification target subject + Country. See note. + type: string + state: + description: >- + Information of certification target subject + State. See note. + type: string + locality: + description: >- + Information of certification target subject + Locality. See note. + type: string + emailAddress: + description: >- + Information of certification contact email + address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of being globally + unique. + type: string + basicConstraints: + type: string + description: | + Basic constraints of certificates. See note. + issuerAltName: + description: >- + Alternative name of issuer of certificates in this + NS. See note. + type: array + items: + type: string + subjectAltName: + description: >- + Alternative name of subject of certificates. Shall + be present when this certificate is used for + encrypted communication using IP address and + subjectAltName attribute of CertificateBaseProfile + in CertificateDesc of VNFD is empty (see ETSI GS + NFV-IFA 011 [7],clause 7.1.19.4). See note + type: array + items: + type: string + nameConstraints: + description: Name constraints of certificates. See note. + type: array + items: + type: string + securityPolicy: + description: | + Security policy to be satisfied for certificate. + type: array + items: + description: > + This type provides input information related to security + policy for certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + maxValidityPeriod: + description: Allowed max validity period for certificates. + type: integer + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: integer + cmfData: + description: > + This type provides input information related to CMF for + certificate management. + type: object + required: + - endPoint + - supportedProtocol + properties: + endPoint: + description: End point of CMF instance. + type: object + required: + - ipAddress + - link + properties: + 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 + link: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + supportedProtocol: + description: Supported protocols by CMF instance. + type: array + items: + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + required: true + VnfInstanceTerminationRequest: + description: Parameters for the VNF termination. + content: + application/json: + schema: + description: "This type represents request parameters for the \"Terminate VNF\" operation. * NOTE:\tIn case of forceful termination, the VNF instance is terminated immediately.\n If the VNF is still in service, this can adversely impact the network service,\n and therefore, the EM needs to determine if forceful termination is applicable\n in the particular situation.\n" + type: object + required: + - terminationType + properties: + terminationType: + description: > + Indicates the type of termination is requested. See note. + Permitted values: * FORCEFUL: The VNFM will shut down the VNF + and release the resources immediately after accepting the + request. * GRACEFUL: The VNFM will first arrange to take the + VNF out of service after accepting the request. Once the + operation of taking the VNF out of service finishes (irrespective of whether it has succeeded or failed) or + once the timer value specified in the "gracefulTerminationTimeout" attribute expires, the VNFM will shut down + the VNF and release the resources. + type: string + enum: + - FORCEFUL + - GRACEFUL + gracefulTerminationTimeout: + description: > + This attribute is only applicable in case of graceful + termination. It defines the time to wait for the VNF to be + taken out of service before shutting down the VNF and + releasing the resources. The unit is seconds. If not given and + the "terminationType" attribute is set to "GRACEFUL", it is + expected that the VNFM waits for the successful taking out of + service of the VNF, no matter how long it takes, before + shutting down the VNF and releasing the resources. + type: integer + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + required: true + VnfInstanceHealRequest: + description: Parameters for the Heal VNF operation. + content: + application/json: + schema: + description: > + This type represents request parameters for the "Heal VNF" + operation. + type: object + properties: + vnfcInstanceId: + description: > + List of identifiers of VNFC instances for which a healing + action is requested. Each identifier references the "id" + attribute in a "VnfcInfo" structure. Cardinality can be "0" to + denote that the request applies to the whole VNF and not a + specific VNFC instance. + type: array + items: + description: | + An identifier with the intention of being globally unique. + type: string + cause: + description: | + Indicates the reason why a healing procedure is required. + type: string + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + healScript: + description: > + Provides link to a script that should be executed as part of + the healing action or a set of rules for healing procedure. + type: string + healingResource: + description: "Indicates the kinds of the virtual resource to be healed. Permitted values:\n •\tVL\n •\tLINKPORT\n •\tSTORAGE\n •\tVIRTUALCP\n •\tCOMPUTE\n •\tOSCONTAINER\n\nDefault value is COMPUTE when the VDUs of the VNF are realized by a set of virtual machines and OSCONTAINER when the VDUs of the VNF are realized by a set of OS containers.\n" + type: array + items: + type: string + enum: + - VL + - LINKPORT + - STORAGE + - VIRTUALCP + - COMPUTE + - OSCONTAINER + required: true + VnfInstanceOperateRequest: + description: Parameters for the Operate VNF operation. + content: + application/json: + schema: + description: "This type represents request parameters for the \"Operate VNF\" operation. * NOTE:\tThe \"stopType\" and \"gracefulStopTimeout\" attributes shall be absent, when the \"changeStateTo\"\n attribute is equal to \"STARTED\". The \"gracefulStopTimeout\" attribute shall be present, when the\n \"changeStateTo\" is equal to \"STOPPED\" and the \"stopType\" attribute is equal to \"GRACEFUL\".\n The \"gracefulStopTimeout\" attribute shall be absent, when the \"changeStateTo\" attribute is equal to\n \"STOPPED\" and the \"stopType\" attribute is equal to \"FORCEFUL\". The request shall be treated as if\n the \"stopType\" attribute has been set to \"FORCEFUL\", when the \"changeStateTo\" attribute is equal\n to \"STOPPED\" and the \"stopType\" attribute is absent.\n" + type: object + required: + - changeStateTo + properties: + vnfcInstanceId: + description: > + List of identifiers of VNFC instances. Each identifier + references the "id" attribute in a "VnfcInfo" structure. + Cardinality can be "0" to denote that the request applies to + the whole VNF and not a specific VNFC instance. + type: array + items: + description: | + An identifier with the intention of being globally unique. + type: string + changeStateTo: + description: > + STARTED: The VNF instance is up and running. STOPPED: The VNF + instance has been shut down. + type: string + enum: + - STARTED + - STOPPED + stopType: + description: > + It signals whether forceful or graceful stop is requested. See + note + type: string + enum: + - FORCEFUL + - GRACEFUL + gracefulStopTimeout: + description: > + The time interval (in seconds) to wait for the VNF to be taken + out of service during graceful stop, before stopping the VNF. + See note. + type: integer + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + required: true + VnfInstanceChangeExtConnRequest: + description: | + Parameters for the Change external VNF connectivity operation. + content: + application/json: + schema: + description: > + This type represents request parameters for the "Change external + VNF connectivity" operation to modify the external connectivity of + a VNF instance. The following behaviour applies for the changes + that can be performed with this operation: + To change the connection of external CP instances based on certain external CPDs from a "source" external + VL to a different "target" external VL, the identifier of the "target" external VL shall be sent in the + "extVirtualLinkId" attribute of the "extVirtualLinks" parameter, and the "extCps" attributes of that parameter + shall refer via the "cpdId" attribute to the external CPDs of the corresponding external connection point + instances that are to be reconnected to the target external VL. + * NOTE 1: For CP instances that are not part of a trunk this means + that all CP instances based on a given external + CPD will be reconnected. See clause B.3.3 for an illustration. Likewise, for CP instances that are part of a + trunk and have the same segmentationId, all CP instances (subports) based on a given external CPD will + be connected, disconnected or reconnected. + + To change the connectivity parameters of the external CPs connected to a particular external VL, including + changing addresses, the identifier of that external VL shall be sent in the "extVirtualLinkId" attribute of the + "extVirtualLinks" parameter, and the "extCps" attribute of that parameter shall contain at least those entries + with modified parameters. + + To create a new external CP instance, this shall be based on a certain external CPD that is referenced by at + least a VDU from which the VNF instance has at least one VNFC instantiated. The newly external CP instance + connects to the same external VL as other CP instances created based on the same CPD. For creating a new + external CP instance: + The "extVirtualLinkId" attribute of the "extVirtualLinks" parameter indicates the identifier of the + external VL instance to which the new external CP instance is requested to be connected (refer to + above behavior). + + The "extCps" attribute shall refer via the "cpdId" attribute to the external CPDs from which a new + instance is to be created. + + * NOTE 2: For the capability to connect to different external VLs, + refer to the use of subports. + To delete an existing external CP instance: + The "extVirtualLinkId" attribute of the "extVirtualLinks" parameter indicates the identifier of the + external VL instance from which the existing external CP instance is requested to be disconnected. + + The "extCpsDeletion" attribute shall refer via the "cpdId" attribute to the external CPD from which a + corresponding CP instance will be deleted. + + The " parentCpConfigId" of the contained "cpConfig" in the "extCps" shall refer to the particular + external CP instance to be deleted. + + * NOTE 3: If external CPs are requested to be created and + connected, and disconnected and deleted in a same + operation request, the consumer can provide respective "extVirtualLinks", e.g., one for the external CPs + to be created and connected, and one for the external CPs to disconnect and delete. + type: object + required: + - extVirtualLinks + properties: + extVirtualLinks: + description: > + Information about external VLs to change (e.g. connect the VNF + to) including configuration information for the CPs via which + the VNF instance can attach to this VL. Entries in the list of + external VLs that are unchanged need not be supplied as part + of this request. The following applies to the + "ExtVirtualLinkData" information provided in this request, + together with the related "ExtVirtualLinkInfo" information + known to the VNFM represented in the "VnfInstance" structure + (see clause 5.5.2.2): Even if the VNF is not in fully + scaled-out state, the API consumer shall provide enough CP + configuration records to allow connecting the VNF instance, + fully scaled out in all scaling aspects, to the external VLs. + type: array + items: + description: "This type represents an external VL. * NOTE 1: The information about the VIM connection referenced by the VIM connection id is known to the VNFM. \n Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2:\t A link port is not needed for an external CP instance that exposes a CP in the following cases:\n 1) For a virtual IP CP directly exposed as an external CP:\n 1.1) No dedicated IP address is allocated as virtual IP address, as indicated in the VNFD.\n 1.2) A dedicated IP address is allocated as virtual IP address, but the NFVO indicates that no port is\n needed (createExtLinkPort in VnfExtCpconfig set to false).\n 2) For a virtual IP CP exposed as an external CP via a floating IP address:\n 2.1) No dedicated IP address is allocated as virtual IP address, as indicated in the VNFD, and the VNFC\n CP associated to the virtual IP CP is also exposed via a floating IP address.\n 3) For a VIRTUAL CP exposed as an external CP.\n 4) For a VNFC CP exposed as an external CP in a secondary container cluster external network.\n\n* NOTE 3: An example of the network attachment definition resource when the container infrastructure service\n management is a Kubernetes® instance is a network attachment definition (NAD).\n\n* NOTE 4: Either \"extCps\" or “extCpsDeletion\" shall be present, but not both.\n" + type: object + required: + - id + - resourceId + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + extCps: + description: > + External CPs of the VNF to be connected to this external + VL. Entries in the list of external CP data that are + unchanged need not be supplied if the ExtVirtualLinkData + structure is part of a request or response that modifies + the external connectivity.See note 4. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. The + entries shall be applied by the VNFM according to + the rules of JSON Merge Patch (see IETF RFC 7396). + See notes 2, 3, 4, 5 and 6. In case of deleting an + external CP, the list of instances to be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the + CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored. + + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + extLinkPorts: + description: > + Externally provided link ports to be used to connect + external connection points to this external VL. If this + attribute is not present, the VNFM shall create the link + ports on the external VL except in the cases defined + below. See note 2. + type: array + items: + description: "This type represents an externally provided link port to be used to connect an external connection point to an external VL. * NOTE:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + extNetAttDefResourceData: + description: > + Externally provided network attachment definition + resource(s) that provide the specification of the + interface to attach external CPs to this external VL. + See note 3. It is only applicable if the external VL is + realized by a secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + This type represents a network attachment definition + resource that provides the specification of the + interface to be used to connect one or multiple + connection points to a secondary container cluster + network realizing a VL. + type: object + required: + - netAttDefResourceId + - resourceHandle + properties: + netAttDefResourceId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + extCpsDeletion: + description: > + External CPs of the VNF to be disconnected from this + external VL and to be deleted. See note 4. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. The + entries shall be applied by the VNFM according to + the rules of JSON Merge Patch (see IETF RFC 7396). + See notes 2, 3, 4, 5 and 6. In case of deleting an + external CP, the list of instances to be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the + CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored. + + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + certificateConfigurationData: + description: > + This type provides input information related to certificate + management. + type: object + required: + - securityPolicy + properties: + overridingCertificateProfile: + description: > + Overriding certificate profile. This overrides the + certificateBaseProfile provided in the VNFD, and the CA + and CMF can additionally override aspects of this + certificateBaseProfile at later point in the VNF lifecycle + if necessary to meet operator security policy. + type: array + items: + description: > + This type provides input information to override + certificate base profile for certificate management + + NOTE : At least one overriding attributes shall be + present, otherwise shall be absent. + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + issuer: + type: string + description: Issuer of certificates. See note. + issuerUniqueIdentifier: + description: > + An identifier with the intention of being globally + unique. + type: string + subject: + description: > + This type provides input information related to + subject of certificate. + + * NOTE: At least one overriding attributes shall be + present, otherwise shall be absent. + type: object + properties: + commonName: + description: >- + Information of certification target subject + FQDN. See note. + type: string + organization: + description: >- + Information of certification target subject + Organization. See note. + type: string + country: + description: >- + Information of certification target subject + Country. See note. + type: string + state: + description: >- + Information of certification target subject + State. See note. + type: string + locality: + description: >- + Information of certification target subject + Locality. See note. + type: string + emailAddress: + description: >- + Information of certification contact email + address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of being globally + unique. + type: string + basicConstraints: + type: string + description: | + Basic constraints of certificates. See note. + issuerAltName: + description: >- + Alternative name of issuer of certificates in this + NS. See note. + type: array + items: + type: string + subjectAltName: + description: >- + Alternative name of subject of certificates. Shall + be present when this certificate is used for + encrypted communication using IP address and + subjectAltName attribute of CertificateBaseProfile + in CertificateDesc of VNFD is empty (see ETSI GS + NFV-IFA 011 [7],clause 7.1.19.4). See note + type: array + items: + type: string + nameConstraints: + description: Name constraints of certificates. See note. + type: array + items: + type: string + securityPolicy: + description: | + Security policy to be satisfied for certificate. + type: array + items: + description: > + This type provides input information related to security + policy for certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + maxValidityPeriod: + description: Allowed max validity period for certificates. + type: integer + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: integer + cmfData: + description: > + This type provides input information related to CMF for + certificate management. + type: object + required: + - endPoint + - supportedProtocol + properties: + endPoint: + description: End point of CMF instance. + type: object + required: + - ipAddress + - link + properties: + 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 + link: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + supportedProtocol: + description: Supported protocols by CMF instance. + type: array + items: + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + required: true + VnfInstanceChangeVnfPkgRequest: + description: | + Parameters for the Change current VNF package operation. + content: + application/json: + schema: + description: "This type represents request parameters for the \"Change current VNF package\" operation to replace the VNF package on which a VNF instance is based. * NOTE 1:\tThe indication of externally-managed internal VLs is needed in case networks have been\n pre-configured for use with certain VNFs, for instance to ensure that these networks have certain\n properties such as security or acceleration features, or to address particular network topologies.\n The present document assumes that externally-managed internal VLs are managed by the NFVO and created\n towards the VIM.\n* NOTE 2: Component mappings are defined in the VNFD in the source or destination package for the relevant change\n path. See clause 7.1.15.2 in ETSI GS NFV-IFA 011 [7].\n* NOTE 3: In the current version of the present document, only Rolling upgrade and Blue-green upgrade types \n are supported. The definition of additional upgrade types is left for future specification.\n" + type: object + required: + - vnfdId + properties: + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + extVirtualLinks: + description: > + Information about external VLs to connect the VNF to, + including configuration information for the CPs via which the + VNF instance can attach to this VL. Entries in the list that + are unchanged need not be supplied as part of this request. + The following applies to the "ExtVirtualLinkData" information + provided in this request, together with the related + "ExtVirtualLinkInfo" information known to the VNFM represented + in the "VnfInstance" structure (see clause 5.5.2.2): Even if + the VNF is not in fully scaled-out state after the change of + the VNF package, the API consumer shall provide enough CP + configuration records to allow connecting the VNF instance, + fully scaled out in all scaling aspects, to the external VLs. + type: array + items: + description: "This type represents an external VL. * NOTE 1: The information about the VIM connection referenced by the VIM connection id is known to the VNFM. \n Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2:\t A link port is not needed for an external CP instance that exposes a CP in the following cases:\n 1) For a virtual IP CP directly exposed as an external CP:\n 1.1) No dedicated IP address is allocated as virtual IP address, as indicated in the VNFD.\n 1.2) A dedicated IP address is allocated as virtual IP address, but the NFVO indicates that no port is\n needed (createExtLinkPort in VnfExtCpconfig set to false).\n 2) For a virtual IP CP exposed as an external CP via a floating IP address:\n 2.1) No dedicated IP address is allocated as virtual IP address, as indicated in the VNFD, and the VNFC\n CP associated to the virtual IP CP is also exposed via a floating IP address.\n 3) For a VIRTUAL CP exposed as an external CP.\n 4) For a VNFC CP exposed as an external CP in a secondary container cluster external network.\n\n* NOTE 3: An example of the network attachment definition resource when the container infrastructure service\n management is a Kubernetes® instance is a network attachment definition (NAD).\n\n* NOTE 4: Either \"extCps\" or “extCpsDeletion\" shall be present, but not both.\n" + type: object + required: + - id + - resourceId + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + extCps: + description: > + External CPs of the VNF to be connected to this external + VL. Entries in the list of external CP data that are + unchanged need not be supplied if the ExtVirtualLinkData + structure is part of a request or response that modifies + the external connectivity.See note 4. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. The + entries shall be applied by the VNFM according to + the rules of JSON Merge Patch (see IETF RFC 7396). + See notes 2, 3, 4, 5 and 6. In case of deleting an + external CP, the list of instances to be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the + CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored. + + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + extLinkPorts: + description: > + Externally provided link ports to be used to connect + external connection points to this external VL. If this + attribute is not present, the VNFM shall create the link + ports on the external VL except in the cases defined + below. See note 2. + type: array + items: + description: "This type represents an externally provided link port to be used to connect an external connection point to an external VL. * NOTE:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + extNetAttDefResourceData: + description: > + Externally provided network attachment definition + resource(s) that provide the specification of the + interface to attach external CPs to this external VL. + See note 3. It is only applicable if the external VL is + realized by a secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + This type represents a network attachment definition + resource that provides the specification of the + interface to be used to connect one or multiple + connection points to a secondary container cluster + network realizing a VL. + type: object + required: + - netAttDefResourceId + - resourceHandle + properties: + netAttDefResourceId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + extCpsDeletion: + description: > + External CPs of the VNF to be disconnected from this + external VL and to be deleted. See note 4. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. The + entries shall be applied by the VNFM according to + the rules of JSON Merge Patch (see IETF RFC 7396). + See notes 2, 3, 4, 5 and 6. In case of deleting an + external CP, the list of instances to be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the + CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored. + + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + extManagedVirtualLinks: + description: > + Information about internal VLs that are managed by other + entities than the VNFM. See note. + type: array + items: + description: "This type represents an externally-managed internal VL. * NOTE:\tThe information about the VIM connection referenced by the VIM connection id is known to the VNFM.\n Moreover, the identifier of the VIM connection provides scope to the resourceId.\n" + type: object + required: + - id + - virtualLinkDescId + - resourceId + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfVirtualLinkDescId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + selectedDeployableModule: + description: > + Identifier of a selected deployable module. If this attribute + is present only VNFCs based on VDUs that belong to deployable + modules listed in this attribute are requested to be + instantiated or preserved if they were already instantiated. + If this attribute is not present the deployable modules that + were selected before the operation, and that still are defined + in the VNFD in the destination package, or the corresponding + ones according to the component mappings, remain valid. See + note 2. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + resourceCapacityDefinition: + description: > + Indicates values for resource capacity related attributes + pertaining to a descriptor. Values can only be provided for + resource capacity related attributes that have been defined in + the VNFD as being configurable. Furthermore, provided values + shall be within the allowed values indicated in the VNFD. + type: array + items: + description: > + This type represents selected values for capacity related + VDU attributes. + + * NOTE: Resource definitions not related to a VDU are not + considered in this version of the present document. + type: object + required: + - type + properties: + tag: + description: >- + Tag assigned by the issuer of a VNF LCM operation + request that contains this data type with values to be + applied to a VDU. It is used for tracking purposes. The + tag is preserved in the run time record as long as at + least one value of the capacity related attributes + associated with that tag is still valid, i.e., it has + not been modified by a later VNF LCM operation request. + At most one tag can be included when the data type is + used in a VNF LCM operation request. When the data type + is used in the VnfInstance data type it may contain + multiple tags, namely those provided in VNF LCM + requests, if at least one of the values provided in that + request associated to that tag is still applicable in + the VNFCs created from this VDU, i.e., it has not been + modified by a later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: "Type of the resource definition referenced. VALUES •\tCOMPUTE •\tSTORAGE •\tOSCONTAINER" + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + osContainerDescData: + description: >- + Indicates values for resource capacity related + attributes in an OsContainerDesc. It shall be present + when the attribute ‘type’ indicates OSCONTAINER and + absent otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of an OsContainer resource. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for the + container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for the + container expressed in the same units as specified + in the requested_memory_resources_valid_values + property in VNFD for this container descriptor. + See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources of the + type indicated in the key. The key is a string + that identifies an extended resource indicated in + the extended_resource_requests property in the + VNFD for this container descriptor. The value is + an integer that indicates the required amount for + a particular extended resource.See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container can + maximally use in milli-CPU. See note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required for all the + hugepages of the size indicated in the key. The + key is a string and corresponds to one of the + values of the hugepage sizes indicated in the + huge_pages_resources property in the VNFD for + this container descriptor. The value is a number + that indicates the required total size expressed + in the same units as in the + huge_pages_resources_property in the VNFD that + indicates the valid values for required total size + for the particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores are + requested to be allocated to logical CPU cores + according to the cpuOperationalPowerStates + attribute. In case of "DYNAMIC", the CPU power + states of virtual CPU cores can be allocated + to logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual compute resource + of a VM. + + * NOTE: At least one of the attributes shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - resourceTemplateId + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required for all the + hugepages of the size indicated in the key. The key + is a string and corresponds to one of the values of + the hugepage sizes indicated in the + huge_pages_requirements property in the VNFD for + this virtual compute descriptor. The value is a + number that indicates the required total size + expressed in the same units as in the + huge_pages_requirements property in the VNFD that + indicates the valid values for required total size + for the particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores are + requested to be allocated to logical CPU cores + according to the cpuOperationalPowerStates + attribute. In case of "DYNAMIC", the CPU power + states of virtual CPU cores can be allocated to + logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size related + attribute in an VirtualStorageDesc. It shall be present + when the attribute 'type' indicates STORAGE and absent + otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual storage + resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + certificateConfigurationData: + description: > + This type provides input information related to certificate + management. + type: object + required: + - securityPolicy + properties: + overridingCertificateProfile: + description: > + Overriding certificate profile. This overrides the + certificateBaseProfile provided in the VNFD, and the CA + and CMF can additionally override aspects of this + certificateBaseProfile at later point in the VNF lifecycle + if necessary to meet operator security policy. + type: array + items: + description: > + This type provides input information to override + certificate base profile for certificate management + + NOTE : At least one overriding attributes shall be + present, otherwise shall be absent. + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + issuer: + type: string + description: Issuer of certificates. See note. + issuerUniqueIdentifier: + description: > + An identifier with the intention of being globally + unique. + type: string + subject: + description: > + This type provides input information related to + subject of certificate. + + * NOTE: At least one overriding attributes shall be + present, otherwise shall be absent. + type: object + properties: + commonName: + description: >- + Information of certification target subject + FQDN. See note. + type: string + organization: + description: >- + Information of certification target subject + Organization. See note. + type: string + country: + description: >- + Information of certification target subject + Country. See note. + type: string + state: + description: >- + Information of certification target subject + State. See note. + type: string + locality: + description: >- + Information of certification target subject + Locality. See note. + type: string + emailAddress: + description: >- + Information of certification contact email + address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of being globally + unique. + type: string + basicConstraints: + type: string + description: | + Basic constraints of certificates. See note. + issuerAltName: + description: >- + Alternative name of issuer of certificates in this + NS. See note. + type: array + items: + type: string + subjectAltName: + description: >- + Alternative name of subject of certificates. Shall + be present when this certificate is used for + encrypted communication using IP address and + subjectAltName attribute of CertificateBaseProfile + in CertificateDesc of VNFD is empty (see ETSI GS + NFV-IFA 011 [7],clause 7.1.19.4). See note + type: array + items: + type: string + nameConstraints: + description: Name constraints of certificates. See note. + type: array + items: + type: string + securityPolicy: + description: | + Security policy to be satisfied for certificate. + type: array + items: + description: > + This type provides input information related to security + policy for certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + maxValidityPeriod: + description: Allowed max validity period for certificates. + type: integer + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: integer + cmfData: + description: > + This type provides input information related to CMF for + certificate management. + type: object + required: + - endPoint + - supportedProtocol + properties: + endPoint: + description: End point of CMF instance. + type: object + required: + - ipAddress + - link + properties: + 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 + link: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + supportedProtocol: + description: Supported protocols by CMF instance. + type: array + items: + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + upgradeType: + description: "Indicates upgrade type when change the current VNF Package on which a VNF instance is based. Permitted values: •\tROLLING_UPGRADE •\tBLUE_GREEN See note 3.\n" + type: string + enum: + - ROLLING_UPGRADE + - BLUE_GREEN + required: true + VnfLcmSubscriptionRequest: + description: | + Details of the subscription to be created. + content: + application/json: + schema: + description: > + This type represents a subscription request related to + notifications about VNF lifecycle changes. + type: object + required: + - callbackUri + properties: + filter: + description: "This type represents a subscription filter related to notifications about VNF lifecycle changes.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of \n the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdIds + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId values + listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, from + one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tVnfLcmOperationOccurrenceNotification -\tVnfIdentifierCreationNotification -\tVnfIdentifierDeletionNotification See note.\n" + type: array + items: + type: string + enum: + - VnfLcmOperationOccurrenceNotification + - VnfIdentifierCreationNotification + - VnfIdentifierDeletionNotification + operationTypes: + description: > + Match particular VNF lifecycle operation types for the + notification of type + VnfLcmOperationOccurrenceNotification. May be present if + the "notificationTypes" attribute contains the value + "VnfLcmOperationOccurrenceNotification", and shall be + absent otherwise. + type: array + items: + description: > + The enumeration LcmOpType defines the permitted values + to represent VNF lifecycle operation types in VNF + lifecycle management operation occurrence resources and + VNF lifecycle management operation occurrence + notifications. + + Value | Description ------|------------ INSTANTIATE | + Represents the "Instantiate VNF" LCM operation. SCALE + | Represents the "Scale VNF" LCM operation. + SCALE_TO_LEVEL | Represents the "Scale VNF to Level" LCM + operation. CHANGE_FLAVOUR | Represents the "Change VNF + Flavour" LCM operation. TERMINATE | Represents the + "Terminate VNF" LCM operation. HEAL | Represents the + "Heal VNF" LCM operation. OPERATE | Represents the + "Operate VNF" LCM operation. CHANGE_EXT_CONN | + Represents the "Change external VNF connectivity" LCM + operation. MODIFY_INFO | Represents the "Modify VNF + Information" LCM operation. CREATE_SNAPSHOT | Represents + the "Create VNF Snapshot" LCM operation. + REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF + Snapshot" LCM operation. CHANGE_VNFPKG | Represents the + "Change current VNF package" LCM operation. + SELECT_DEPL_MODS | Represents the "Select VNF + deployable modules" LCM operation + type: string + enum: + - INSTANTIATE + - SCALE + - SCALE_TO_LEVEL + - CHANGE_FLAVOUR + - TERMINATE + - HEAL + - OPERATE + - CHANGE_EXT_CONN + - MODIFY_INFO + - CREATE_SNAPSHOT + - REVERT_TO_SNAPSHOT + - CHANGE_VNFPKG + - SELECT_DEPL_MODS + operationStates: + description: > + Match particular LCM operation state values as reported in + notifications of type + VnfLcmOperationOccurrenceNotification. May be present if + the "notificationTypes" attribute contains the value + "VnfLcmOperationOccurrenceNotification", and shall be + absent otherwise. + type: array + items: + description: > + STARTING: The LCM operation is starting. PROCESSING: The + LCM operation is currently in execution. COMPLETED: The + LCM operation has been completed successfully. + FAILED_TEMP: The LCM operation has failed and execution + has stopped, but the execution of the operation is not + considered to be closed. FAILED: The LCM operation has + failed and it cannot be retried or rolled back, as it is + determined that such action won't succeed. ROLLING_BACK: + The LCM operation is currently being rolled back. + ROLLED_BACK: The LCM operation has been successfully + rolled back, i.e. The state of the VNF prior to the + original operation invocation has been restored as + closely as possible. + type: string + enum: + - STARTING + - PROCESSING + - COMPLETED + - FAILED_TEMP + - FAILED + - ROLLING_BACK + - ROLLED_BACK + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + authentication: + description: > + * NOTE 1 : The clientId and clientPassword passed in a + subscription shall not be the same as the clientId and + clientPassword that are used to obtain authorization for API requests. Client credentials may differ between + subscriptions. The value of clientPassword should be generated by a random process. + * NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT + which uses mutual authentication based on X.509 + certificates, this mode which uses client password to authenticate may be used in the access token request + toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations + (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details. + * NOTE 3: The following values that were included up to + version 3.4.1 of the present document have been removed: + "BASIC" (to signal the use of the basic HTTP authentication) has been removed because it is insecure. + "TLS_CERT" to signal an alternative non-token based authorization method using TLS certificates has been + removed because the method is no longer supported. + * NOTE 4: The client certificate is established by means + outside the scope of the present document. + type: object + required: + - authType + properties: + authType: + description: > + Defines the types of Authentication / Authorization which + the API consumer is willing to accept when receiving a + notification. Permitted values (see note 3): * + OAUTH2_CLIENT_CREDENTIALS: In every + HTTP request to the notification endpoint, use + an OAuth 2.0 token, obtained using the client + credentials grant type after authenticating + using client identifier and client password + towards the token endpoint. + * OAUTH2_CLIENT_CERT: In every HTTP + request to the notification endpoint, use an + OAuth 2.0 token, obtained using the client + credentials grant type after mutually + authenticating using client identifier and X.509 + certificates towards the token endpoint. + type: array + items: + type: string + enum: + - OAUTH2_CLIENT_CREDENTIALS + - OAUTH2_CLIENT_CERT + paramsOauth2ClientCert: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CERT. + + Shall be present if authType is "OAUTH2_CLIENT_CERT" and + the contained information has not been provisioned out of + band. + + Shall be absent otherwise. + type: object + required: + - clientId + - certificateRef + - tokenEndpoint + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. + type: string + certificateRef: + description: > + Fingerprint of the client certificate. The hash + function shall use SHA256 or higher. See note 4. + type: string + required: + - type + - value + properties: + type: + description: | + A string defined in IETF RFC 8259. + type: string + value: + description: | + A string defined in IETF RFC 8259. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + paramsOauth2ClientCredentials: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CREDENTIALS. + + Shall be present if authType is + "OAUTH2_CLIENT_CREDENTIALS" and the contained information + has not been provisioned out of band. + + Shall be absent otherwise. + + See note 2. + type: object + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. Shall be present if it has not been + provisioned out of band. See note 1. + type: string + clientPassword: + description: > + Client password to be used in the access token request + of the OAuth 2.0 client credentials grant type. Shall + be present if it has not been provisioned out of band. + See note 1. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + verbosity: + description: > + The enumeration LcmOpOccNotificationVerbosityType provides + values to control the verbosity of LCM operation occurrence + notifications. * FULL: This signals a full notification which + contains all change details. * SHORT: This signals a short + notification which omits large-volume change details to reduce + the size of data to + be sent via the notification mechanism. + type: string + enum: + - FULL + - SHORT + required: true + VnfInstanceCreateSnapshotRequest: + description: | + Parameters for the “Create VNF/VNFC Snapshot” operation. + content: + application/json: + schema: + description: > + This type represents request parameters for the "Create VNF + Snapshot" operation. + type: object + required: + - vnfSnapshotResId + properties: + vnfSnapshotInfoId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfcInstanceId: + description: > + An identifier that is unique for the respective type within a + VNF instance, but may not be globally unique. + type: string + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + userDefinedData: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + required: true + VnfInstanceRevertToSnapshotRequest: + description: | + Parameters for the Revert-to VNF/VNFC snapshot operation. + content: + application/json: + schema: + description: > + This type represents request parameters for the "Revert-to VNF + Snapshot" operation. + type: object + properties: + vnfSnapshotInfoId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfcInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfcSnapshotInfoId: + description: | + An identifier with the intention of being globally unique. + type: string + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + required: true + VnfSnapshotsRequest: + description: | + The VNF snapshot resource creation parameters. + content: + application/json: + schema: + description: > + This type represents request parameters for the creation of an + "Individual VNF snapshot" resource which can be + + populated with content obtained by invoking the "Create VNF + snapshot" LCM operation or extracted from a VNF + + snapshot package. + + * NOTE: The present attribute shall be provided if the "Individual + VNF snapshot" resource + is requested to be created and be filled from a VNF snapshot package extraction. + type: object + properties: + vnfSnapshotPkgId: + description: | + An identifier with the intention of being globally unique. + type: string + required: true + responses: + VnfInstances.Get.200: + description: > + 200 OK + + Shall be returned when information about zero or more VNF instances has + been queried successfully. + + The response body shall contain in an array the representations of zero + or more VNF instances, + + as defined in clause 5.5.2.2. + + If the "filter" URI parameter or one of the "all_fields", "fields" (if + supported), "exclude_fields" + + (if supported) or "exclude_default" URI parameters was supplied in the + request, the data in the response + + body shall have been transformed according to the rules specified in + clauses 5.2.2 and 5.3.2 of + + ETSI GS NFV-SOL 013, respectively. + + If the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 + of ETSI GS NFV-SOL 013 + + for this resource, inclusion of the Link HTTP header in this response + shall follow the provisions + + in clause 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: "This type represents a VNF instance. * NOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist\n between the previous and the newly referred VNF package, i.e. when the new VNFD is\n changed with respect to the previous VNFD in other aspects than merely referencing\n to other VNF software images. In order to avoid misalignment of the VnfInstance with\n the current VNF's on-boarded VNF package, the values of attributes in the VnfInstance\n that have corresponding attributes in the VNFD shall be kept in sync with the values in the VNFD.\n* NOTE 2:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 3:\tThese attributes are sometimes also referred to as configuration parameters\n applicable to a VNF. Some of these are set prior to instantiation and cannot be modified\n if the VNF is instantiated, some are set prior to instantiation (are part of initial configuration)\n and can be modified later, and others can be set only after instantiation.\n The applicability of certain configuration may depend on the VNF and the required operation of\n the VNF at a certain point in time.\n* NOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child\n attributes of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared\n in the VNFD with a defined initial value. The defined initial values can be declared in the VNFD,\n and/or, in case of \"metadata\", obtained from the \"CreateVnfRequest\" structure. Child attributes of\n \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that have no defined initial value shall\n not be created, in order to be consistent with the semantics of the JSON Merge Patch method\n (see IETF RFC 7396) that interprets null values as deletion request.\n* NOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case\n of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding\n to the same VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc\n and externally-managed multi-site VL instance (refer to clause 5.5.3.5).\n* NOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity,\n they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n* NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual extCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the VNF \n LCM operation explicitly indicates the scale level for the aspect.\n* NOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n" + type: object + required: + - id + - vnfdId + - vnfProvider + - vnfProductName + - vnfSoftwareVersion + - vnfdVersion + - instantiationState + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfInstanceName: + description: > + Name of the VNF instance. This attribute can be modified + with the PATCH method. + type: string + vnfInstanceDescription: + description: > + Human-readable description of the VNF instance. This + attribute can be modified with the PATCH method. + type: string + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfProvider: + description: > + Provider of the VNF and the VNFD. The value is copied from + the VNFD. + type: string + vnfProductName: + description: > + Name to identify the VNF Product. The value is copied from + the VNFD. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + certificateInfo: + description: > + This type provides input information related to certificate + and certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + certificateConfigurationInfo: + description: > + This type provides input information related to + certificate management. + type: object + required: + - securityPolicy + properties: + certificateBaseProfile: + description: > + This type provides input information to override + certificate base profile for certificate management + + NOTE : At least one overriding attributes shall be + present, otherwise shall be absent. + required: + - id + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + issuer: + type: string + description: Issuer of certificates. See note. + issuerUniqueIdentifier: + description: > + An identifier with the intention of being + globally unique. + type: string + subject: + description: > + This type provides input information related to + subject of certificate. + + * NOTE: At least one overriding attributes shall + be present, otherwise shall be absent. + type: object + properties: + commonName: + description: >- + Information of certification target subject + FQDN. See note. + type: string + organization: + description: >- + Information of certification target subject + Organization. See note. + type: string + country: + description: >- + Information of certification target subject + Country. See note. + type: string + state: + description: >- + Information of certification target subject + State. See note. + type: string + locality: + description: >- + Information of certification target subject + Locality. See note. + type: string + emailAddress: + description: >- + Information of certification contact email + address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of being + globally unique. + type: string + basicConstraints: + type: string + description: | + Basic constraints of certificates. See note. + issuerAltName: + description: >- + Alternative name of issuer of certificates in + this NS. See note. + type: array + items: + type: string + subjectAltName: + description: >- + Alternative name of subject of certificates. + Shall be present when this certificate is used + for encrypted communication using IP address and + subjectAltName attribute of + CertificateBaseProfile in CertificateDesc of + VNFD is empty (see ETSI GS NFV-IFA 011 + [7],clause 7.1.19.4). See note + type: array + items: + type: string + nameConstraints: + description: Name constraints of certificates. See note. + type: array + items: + type: string + securityPolicy: + description: > + Information for security policy to be satisfied for + certificate. + type: array + items: + description: > + This type provides input information related to + security policy for certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + maxValidityPeriod: + description: Allowed max validity period for certificates. + type: integer + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: integer + delegationSupportedCertificateManagements: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + cmfInfo: + description: > + This type provides input information related to CMF + for certificate management. + type: object + required: + - id + - endPoint + - supportedProtocol + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + endPoint: + description: End point of CMF instance. + type: object + required: + - ipAddress + - link + properties: + 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 + link: + description: > + This type represents a link to a resource + using an absolute URI. + type: object + required: + - href + properties: + href: + description: > + String formatted according to IETF RFC + 3986. + type: string + supportedProtocols: + description: Supported protocol by CMF instance. + type: array + items: + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + certificateChain: + description: Certificate chain that this CMF provides. + type: array + items: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + certificateContents: + description: > + Information for contents of issued certificates. The + information contained in this attribute may be updated + over time during the VNF LCM, e.g. certificate(s) + renewal. + type: array + items: + description: > + This type provides input information related to + certificate content. + type: object + required: + - id + - certificateDescId + - certificateType + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + certficateDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + certificateType: + description: Type of this certificate. + type: string + enum: + - VNFCI_CERT + - VNFOAM_CERT + supportedCertificateManagements: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + version: + description: | + A version. + type: string + serialNumber: + description: Serial number of this certificate. + type: integer + signatureAlgorithm: + description: Algorithm of this certificate's signature. + type: string + issuer: + description: Issuer of this certificate. + type: string + notBefore: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + notAfter: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + subject: + description: Subject of this certificate. + type: string + publicKeyAlgorithm: + description: Algorithm of this certificate's public key. + type: string + publicKey: + description: Public key of this certificate. + type: string + certificateExtensions: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + instantiationState: + description: | + The instantiation state of the VNF. + type: string + enum: + - NOT_INSTANTIATED + - INSTANTIATED + instantiatedVnfInfo: + description: > + Information specific to an instantiated VNF instance. This + attribute shall be present if the instantiateState attribute + value is INSTANTIATED. + type: object + required: + - flavourId + - vnfState + - extCpInfo + properties: + flavourId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfState: + description: > + STARTED: The VNF instance is up and running. STOPPED: + The VNF instance has been shut down. + type: string + enum: + - STARTED + - STOPPED + vnfPowerState: + description: > + This type represents information about the power state + of a VNF instance. + type: object + required: + - powerProfileId + - name + properties: + powerProfileId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + name: + description: | + Name of the power profile as provided in the VNFD. + type: string + powerConsumptionInfo: + description: > + This type represents information about estimated + power consumption of the resources associated with + the power profile, as provided in the VNFD. + type: object + required: + - minPowerConsumption + - maxPowerConsumption + - averagePowerConsumption + properties: + minPowerConsumption: + description: > + Minimum power consumption of this power profile. + Unit is KW/h. + type: integer + maxPowerConsumption: + description: > + Maximum power consumption of this power profile. + Unit is KW/h. + type: integer + averagePowerConsumption: + description: > + Average power consumption of this power profile. + Unit is KW/h. + type: integer + scaleStatus: + description: > + Scale status of the VNF, one entry per aspect. + Represents for every scaling aspect how "big" the VNF + has been scaled w.r.t. that aspect. This attribute shall + be present if the VNF supports scaling. See clause B.2 + for an explanation of VNF scaling. For an aspect that + has not been deployed because the related + deployableModule has not been selected, it indicates the + scale level that has been requested in the instantiation + or in a scaling operation, or, if none has been + requested in any of them, the scale level applicable to + the aspect based on the default instantiation level. See + note 8. + type: array + items: + description: > + This type represents the scale level of a VNF instance + related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + scaleLevel: + description: > + Indicates the scale level. The minimum value shall + be 0 and the maximum value shall be <= + maxScaleLevel as described in the VNFD. + type: integer + maxScaleLevels: + description: > + Maximum allowed scale levels of the VNF, one entry per + aspect. This attribute shall be present if the VNF + supports scaling. + type: array + items: + description: > + This type represents the scale level of a VNF instance + related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + scaleLevel: + description: > + Indicates the scale level. The minimum value shall + be 0 and the maximum value shall be <= + maxScaleLevel as described in the VNFD. + type: integer + selectedDeployableModule: + description: > + References a currently selected deployable module, as + defined in the VNFD, that has already completed the + instantiation of its VNFCs + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + resourceCapacityDefinition: + description: > + Shows current values of VDU attributes related to + resource capacity, if different to the default values + from the VNFD, as indicated in the (one or more) + request(s) of all completed VNF LCM operation(s) that + contain this attribute. If an attribute value has been + modified multiple times, only the last value is shown. + The values indicated in this attribute are applicable to + all VNFC instances based on the VDU to which the + resourceCapacityDefinition is related. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes. + + * NOTE: Resource definitions not related to a VDU are + not considered in this version of the present + document. + type: object + required: + - type + properties: + tag: + description: >- + Tag assigned by the issuer of a VNF LCM operation + request that contains this data type with values + to be applied to a VDU. It is used for tracking + purposes. The tag is preserved in the run time + record as long as at least one value of the + capacity related attributes associated with that + tag is still valid, i.e., it has not been modified + by a later VNF LCM operation request. At most one + tag can be included when the data type is used in + a VNF LCM operation request. When the data type is + used in the VnfInstance data type it may contain + multiple tags, namely those provided in VNF LCM + requests, if at least one of the values provided + in that request associated to that tag is still + applicable in the VNFCs created from this VDU, + i.e., it has not been modified by a later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: "Type of the resource definition referenced. VALUES •\tCOMPUTE •\tSTORAGE •\tOSCONTAINER" + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + osContainerDescData: + description: >- + Indicates values for resource capacity related + attributes in an OsContainerDesc. It shall be + present when the attribute ‘type’ indicates + OSCONTAINER and absent otherwise. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes of an + OsContainer resource. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for the + container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for the + container expressed in the same units as + specified in the + requested_memory_resources_valid_values + property in VNFD for this container + descriptor. See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources of + the type indicated in the key. The key is a + string that identifies an extended resource + indicated in the extended_resource_requests + property in the VNFD for this container + descriptor. The value is an integer that + indicates the required amount for a + particular extended resource.See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container can + maximally use in milli-CPU. See note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required for + all the hugepages of the size indicated in + the key. The key is a string and corresponds + to one of the values of the hugepage sizes + indicated in the huge_pages_resources + property in the VNFD for this container + descriptor. The value is a number that + indicates the required total size expressed + in the same units as in the + huge_pages_resources_property in the VNFD + that indicates the valid values for required + total size for the particular hugepage size. + See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute + or OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU + cores are requested to be allocated to + logical CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states + of virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on + core utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual compute + resource of a VM. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - resourceTemplateId + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required for all + the hugepages of the size indicated in the + key. The key is a string and corresponds to + one of the values of the hugepage sizes + indicated in the huge_pages_requirements + property in the VNFD for this virtual compute + descriptor. The value is a number that + indicates the required total size expressed in + the same units as in the + huge_pages_requirements property in the VNFD + that indicates the valid values for required + total size for the particular hugepage size. + See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or + OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores + are requested to be allocated to logical + CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states of + virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size related + attribute in an VirtualStorageDesc. It shall be + present when the attribute 'type' indicates + STORAGE and absent otherwise. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes of the virtual + storage resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + extCpInfo: + description: > + Information about the external CPs exposed by the VNF + instance. When trunking is enabled, the list of entries + includes both, external CPs corresponding to parent + ports of a trunk, and external CPs associated to + sub-ports of a trunk. See note 7. + type: array + minItems: 1 + items: + description: "This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n" + type: object + required: + - id + - cpdId + - cpConfigId + - cpProtocolInfo + oneOf: + - required: + - associatedVnfcCpId + - required: + - associatedVipCpId + - required: + - associatedVnfVirtualLinkId + properties: + id: + 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 + cpConfigId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + cpProtocolInfo: + description: | + Network protocol information for this CP. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and protocol(s) + associated to the network address + information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned to a + virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and + been associated to the CP. + type: array + items: + type: string + extLinkPortId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + associatedVnfcCpId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + associatedVipCpId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + associatedVirtualCpId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + associatedVnfVirtualLinkId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceInfo” + structure that provides the specification of the + interface to attach the connection point to a + secondary container cluster network. See notes 3 + and 4. It shall be present if the external CP is + associated to a VNFC realized by one or a set of + OS containers and is connected to a secondary + container cluster network. It shall not be present + otherwise. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + certificateContentId: + description: > + An identifier with the intention of being globally + unique. + type: string + cpSecurityGroupInfo: + description: > + This type provides the list of active security + group rules applied to an external CP instance. + The type identifies which "SecurityGroupRule" + specified in the VNFD are activated and the values + of its attributes. + type: object + required: + - securityGroupRuleId + - etherType + - protocol + - portRangeMin + - portRangeMax + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + description: + description: > + Human readable description of the security + group rule. + type: string + etherType: + description: > + Indicates the protocol carried over the + Ethernet layer. Permitted values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + protocol: + description: > + Indicates the protocol carried over the IP + layer. Permitted values: any protocol defined + in the IANA protocol registry (refer to clause + 9.10.1.2 ofd ETSI GS NFV-SOL 001 for further + information). + type: string + portRangeMin: + description: > + Value for the minimum port number in the range + that is matched by the security group rule. + type: integer + portRangeMax: + description: > + Value for the maximum port number in the range + that is matched by the security group rule. + type: integer + vipCpInfo: + description: > + VIP CPs that are part of the VNF instance. Shall be + present when that particular VIP CP of the VNFC instance + is associated to an external CP of the VNF instance. + + May be present otherwise. + type: array + items: + description: "This type provides information related to virtual IP CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n" + type: object + required: + - cpInstanceId + - cpdId + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There shall be + one cpProtocolInfo for layer 3. There may be one + cpProtocolInfo for layer 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and protocol(s) + associated to the network address + information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned to a + virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and + been associated to the CP. + type: array + items: + type: string + associatedVnfcCpIds: + description: > + Identifiers of the VnfcCps that share the virtual + IP address allocated to the VIP CP instance. See + note. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + virtualCpInfo: + description: > + Virtual CPs that are part of the VNF instance. Shall be + present when a particular virtual CP is associated to + an external CP of the VNF instance. May be present + otherwise. + type: array + items: + description: > + This type provides information related to a virtual CP + instance of a VNF. + + * NOTE 1: A consumer of the VNF LCM interface can + learn the actual VNFC instances implementing the + service + accessible via the virtual CP instance by querying the "vnfcResourceInfo" from the "InstantiatedVnfInfo" + and filtering by corresponding "vduIds" values. + * NOTE 2: The information can be omitted because it is + already available as part of the external CP + information in the + VnfExtCpInfo structure. + type: object + required: + - cpInstanceId + - cpdId + - resourceHandle + - vduIds + properties: + cpInstanceId: + 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 + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There shall be + one cpProtocolInfo for each layer protocol + supported. This attribute may be omitted if the + virtual CP is exposed as an external CP. See note + 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and protocol(s) + associated to the network address + information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned to a + virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and + been associated to the CP. + type: array + items: + type: string + vduIds: + description: > + Reference to the VDU(s) which implement the + service accessible via the virtual CP instance. + See note. + type: array + minItems: 1 + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + additionalServiceInfo: + description: > + Additional service identification information of + the virtual CP instance. + type: array + items: + description: > + This type provides additional service + information of the virtual CP instance used to + expose properties of the virtual CP to + NFV-MANO. + + NOTE: This attribute shall only be present if + additional information is needed to identify the + service + termination within the VNF, such as for example a URL path information in an HTTP request required + to allow a single virtual CP IP address to be used for several HTTP based services that use the + same port number. + type: object + required: + - portInfo + properties: + portInfo: + description: > + Service port numbers exposed by the virtual + CP instance. + minItems: 1 + type: array + items: + description: > + This type describes the service + identifying port properties exposed by the + virtual CP instance. + type: object + required: + - name + - port + - portConfigurable + properties: + name: + description: > + The name of the port exposed by the + virtual CP instance. + type: string + protocol: + description: > + The L4 protocol for this port exposed by + the virtual CP instance. + + Permitted values: - TCP - UDP - SCTP + type: string + enum: + - TCP + - UDP + - SCTP + port: + description: > + The L4 port number exposed by the + virtual CP instance. + type: integer + portConfigurable: + description: > + The Boolean is a data type having two + values (true and false). + type: boolean + serviceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + extVirtualLinkInfo: + description: > + Information about the external VLs the VNF instance is + connected to. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the current CP + configuration information for the connection of + external CPs to the external virtual link. See + note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be + configured on the CP instances created from + the respective CPD. The key of the map which + identifies the individual VnfExtCpConfig + entries is of type "IdentifierInVnf" and is + managed by the NFVO. The entries shall be + applied by the VNFM according to the rules + of JSON Merge Patch (see IETF RFC 7396). See + notes 2, 3, 4, 5 and 6. In case of deleting + an external CP, the list of instances to be + deleted. + type: object + additionalProperties: + description: > + This type represents an externally + provided link port, or a network + attachment definition resource of + secondary container cluster network, or + network address information per instance + of an external connection point. In the + case of VM-based deployment of the VNFC + exposing the external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment + of the VNFC exposing the external CP, the + VNFM shall use the network attachment + definition resource of secondary container + cluster network when connecting the CP to + the external VL. + + * NOTE 1: The following conditions apply + to the attributes "linkPortId" and + "cpProtocolData" for an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply + to the attributes “netAttDefResourceId” + and “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is + only applicable for specific cases where + more than one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but + not both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of + being globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create + a dedicated link port for the external + CP. If set to True, the VNFM shall + create a link port. If set to False, the + VNFM shall not create a link port. This + attribute is only applicable for + external CP instances without a floating + IP address that expose a VIP CP instance + for which a dedicated IP address is + allocated. It shall be present in that + case and shall be absent otherwise. + type: boolean + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects + the CP to a VL and the domain names for + the external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the + CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored. + + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security + groups. The parameters identify which + "SecurityGroupRule" specified in the + VNFD is activated/deactivated and for an + activated security group rule the values + of attributes defined in the VNFD that + can be overriden such as "portRangeMin" + and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceData” structure that + provides the specification of the + interface to attach the external CP to a + secondary container cluster network. It + is only applicable if the external CP is + connected or to be connected to a + secondary container cluster network. It + shall not be present if the external CP + is related to a virtual network not + categorized as secondary container + cluster network. See notes 2, 3 and 4. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + extNetAttDefResource: + description: > + Network attachment definition resources that + provide the specification of the interface to + attach connection points to this VL. + type: array + items: + description: > + This type contains information related to a + network attachment definition resource that + provides the specification of the interface + used to connect one or multiple connection + points to a secondary container cluster + network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of being + globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated to + this network attachment definition resource. + Shall be present when the network + attachment definition resource is used for + external connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to this + network attachment definition resource. May + be present when the network attachment + definition resource is used for internal + connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + routingResource: + description: > + Network resources that provide the + forwarding/routing capabilities associated to the + network resource realizing this VL. + type: array + items: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used + by a VNF instance. Information about the + resource is available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id + is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See + note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the + VIM or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall + be absent otherwise. + type: string + extManagedVirtualLinkInfo: + description: > + Information about the externally managed internal VLs of + the VNF instance. See note 5 and note 6. It is possible + to have several ExtManagedVirtualLinkInfo for the same + VNF internal VL in case of a multi-site VNF spanning + several VIMs. The set of ExtManagedVirtualLinkInfo + corresponding to the same VNF internal VL shall indicate + so by referencing to the same VnfVirtualLinkDesc and + externally-managed multi-site VL instance (refer to + clause 5.5.3.5). Even though externally-managed internal + VLs are also used for VNF-internal connectivity, they + shall not be listed in the "vnfVirtualLinkResourceInfo" + attribute as this would be redundant. + type: array + items: + description: > + This type provides information about an + externally-managed virtual link. *NOTE: Both + vnfLinkPort and vnfNetAttDefResource can be present in + an ExtManagedVirtualLinkInfo to indicate that + a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + vnfLinkPorts: + description: | + Link ports of this VL.See note. + type: array + items: + description: > + This type represents a link port of an internal + VL of a VNF. + + NOTE 1: Either cpInstanceId with cpInstanceType + set to "EXT_CP" or any combination of + cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 + provides examples for configurations where both + vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is scoped + by the value of "vimConnectionId" in the + "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vnfNetAttDefResource: + description: > + Network attachment definition resources that + provide the specification of the interface to + attach connection points to this VL. + type: array + items: + description: > + This type contains information related to a + network attachment definition resource that + provides the specification of the interface + used to connect one or multiple connection + points to a secondary container cluster + network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of being + globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated to + this network attachment definition resource. + Shall be present when the network + attachment definition resource is used for + external connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to this + network attachment definition resource. May + be present when the network attachment + definition resource is used for internal + connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + routingResource: + description: > + Network resources that provide the + forwarding/routing capabilities associated to the + network resource realizing this VL. + type: array + items: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used + by a VNF instance. Information about the + resource is available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id + is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See + note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the + VIM or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall + be absent otherwise. + type: string + monitoringParameters: + description: | + Active monitoring parameters. + type: array + items: + type: object + required: + - id + - performanceMetric + properties: + id: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + name: + description: > + Human readable name of the monitoring parameter, + as defined in the VNFD. + type: string + performanceMetric: + description: > + Performance metric that is monitored. This + attribute shall contain the related "Measurement + Name" value as defined in clause 7.2 of ETSI GS + NFV-IFA 027. + type: string + localizationLanguage: + description: > + Information about localization language of the VNF + (includes e.g. strings in the VNFD). The localization + languages supported by a VNF can be declared in the + VNFD, and localization language selection can take place + at instantiation time. The value shall comply with the + format defined in IETF RFC 5646. + type: string + vnfcResourceInfo: + description: > + Information about the virtualised compute and storage + resources used by the VNFCs of the VNF instance. + type: array + items: + description: "This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure \n of information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n - For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n - For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\n\n* NOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an internal VL that\n exposes an external CP. A VNFC CP is \"exposed as\" an external CP if it is connected directly\n to an external VL.\n* NOTE 3:\tThe information can be omitted because it is already available as part of the external CP information. * NOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\" structure by \n an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVnfc\"\n structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to \n this LCM operation occurrence.\n* NOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment \n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build \n a link redundant mated pair in SR-IOV cases.\n* NOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. * NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n" + type: object + required: + - id + - vduId + - computeResource + properties: + id: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + storageResourceIds: + description: > + References to the VirtualStorage resources or + references to Storage MCIO(s). The value refers + to a VirtualStorageResourceInfo item in the + VnfInstance. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfcCpInfo: + description: | + All the CPs of the VNFC instance. See note 7. + type: array + items: + type: object + required: + - id + - cpdId + properties: + id: + 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 + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpProtocolInfo: + description: > + Network protocol information for this CP. + May be omitted if the VNFC CP is exposed as + an external CP. The information can be + omitted because it is already available as + part of the external CP information. See + note 3. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + parentCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceInfo” + structure that provides the specification of + the interface to attach the connection + point to a secondary container cluster + network. See notes 5 and 6. It shall be + present if the internal CP is associated to + a VNFC realized by one or a set of OS + containers and is connected to a secondary + container cluster network. It shall not be + present otherwise. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this VNFC CP + instance uses. Shall be present when using + in delegation-mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of the + certificate(s) that this VNFC CP instance uses. + Shall be present when using in delegation-mode. + Otherwise shall not be present. This attribute + shall be supported when delegation mode in + certificate management is applicable. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfVirtualLinkResourceInfo: + description: > + Information about the virtualised network resources used + by the VLs of the VNF instance. See note 6. Even though + externally-managed internal VLs are also used for + VNF-internal connectivity, they shall not be listed in + the "vnfVirtualLinkResourceInfo" attribute as this would + be redundant. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used by an + internal VL instance in a VNF instance. NOTE: If only + the value or the presence of this attribute is changed + in the "VnfVirtualLinkResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires including a + related "AffectedVirtualLink" structure in the VNF LCM operation occurrence notifications or the + "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + - vnfLinkPorts + properties: + id: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + reservationId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfLinkPorts: + description: > + Links ports of this VL. Shall be present when the + linkPort is used for external connectivity by the + VNF (refer to VnfLinkPortInfo). May be present + otherwise. + type: array + items: + description: > + This type represents a link port of an internal + VL of a VNF. + + NOTE 1: Either cpInstanceId with cpInstanceType + set to "EXT_CP" or any combination of + cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 + provides examples for configurations where both + vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is scoped + by the value of "vimConnectionId" in the + "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + metadata: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + virtualStorageResourceInfo: + description: > + Information on the virtualised storage resource(s) used + as storage for the VNF instance. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. + + NOTE: If only the value or the presence of this + attribute is changed in the + "VirtualStorageResourceInfo" structure by an LCM + operation occurrence, this does not represent a change + that requires including a related + "AffectedVirtualStorage" structure in the VNF LCM + operation occurrence notifications or the + "VnfLcmOpOcc" structure related to this LCM operation + occurrence. + type: object + required: + - id + - virtualStorageDescId + - storageResource + properties: + id: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + reservationId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + vnfcInfo: + description: | + Information about the VNFC instances. + type: array + items: + description: "This type represents the information about a VNFC instance that is part of a VNF instance. * NOTE:\tThis allows to represent the error condition that a VNFC instance has lost its resources.\n" + type: object + required: + - id + - vduId + - vnfcState + properties: + id: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vduId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfcResourceInfoId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfcState: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfcConfigurableProperties: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + mcioInfo: + description: > + Information on the MCIO(s) representing VNFC instance(s) + realized by one or a set of OS containers and created + from the same VDU for the VNF instance. + type: array + items: + description: > + This type provides information about an MCIO + representing the set of VNFC instances realized by + one or a set of OS containers which have been created + based on the same VDU. Within the CISM, an MCIO + controller monitors the actual state of an MCIO + representing the set of VNFC instances realized by + one or a set of OS containers and compare it to the + desired state. For an MCIO related to a VDU that has + the attribute "isNumOfInstancesClusterBased" set to + FALSE the desired state is specified in the respective + declarative descriptor. For an MCIO related to a VDU + that has the attribute "isNumOfInstancesClusterBased" + set to TRUE, the desired state is determined by the + number of CIS-nodes in the cluster that fulfil the VDU + requirements. It triggers actions toward the CIS to + align the actual to the desired state. Monitoring the + actual state includes monitoring the number of MCIO + instances available at any specific point in time. In + addition, an MCIO controller maintains properties and + runtime information on the MCIO instances which have + been created based on the same VDU. The McioInfo data + structure provides the runtime information on the + MCIOs obtained from the MCIO controller. + + NOTE: There are different types of MCIOs. The set of + VNFC instances based on the same VDU is represented + by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type + of MCIO, e.g. a POD. + + Runtime information of the set of OS containers + realizing an individual VNFC instance is not part of + the McioInfo data structure; such runtime information + is provided in the ResourceHandle data structure + referenced from the VnfcResourceInfo. The McioInfo + does not provide runtime information of a constituent + VNFC instance created based on a specific VDU. + + NOTE 1: The type of MCIO as specified in the + declarative descriptor of the MCIO, and that can be + read from + the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the + “kind” property of the declarative descriptor. + NOTE 2: If the attribute additionalInfo is present, it + may contain runtime information on the actual and + desired state of the MCIO(s). + NOTE 3: When the container infrastructure service is a + Kubernetes® instance, the mcioId is the combined + values from the kind and name fields of the Kubernetes resource object, separated by a slash. + Example: "Deployment/abcd". + NOTE 4: When the container infrastructure service is a + Kubernetes® instance, the mcioName is the name + field of the resource object. + type: object + required: + - mcioId + - mcioName + - mcioNamespace + - vduId + - cismId + - mcioType + - desiredInstances + - availableInstances + properties: + mcioId: + description: > + An identifier with the intention of being globally + unique. + type: string + mcioName: + description: | + Human readable name of this MCIO. See note 4. + type: string + mcioNamespace: + description: | + Namespace of this MCIO. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cismId: + description: > + An identifier with the intention of being globally + unique. + type: string + mcioType: + description: > + The type of MCIO. Specific values, their semantics + and associated MCIO types are defined in clause + 5.5.4.9. Additional values are also permitted. See + note 1. + type: string + enum: + - Deployment + - StatefulSet + - DaemonSet + desiredInstances: + description: | + Number of desired MCIO instances. + type: integer + availableInstances: + description: | + Number of available MCIO instances. + type: integer + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + certificateContentId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfPaasServiceInfo: + description: > + Information on the PaaS Services assigned and used by + the VNF instance. + type: array + items: + description: > + This type provides information about a PaaS Service + that is used by a VNF instance. The PaasServiceInfo is + comprised of various sets of information. Some + information comes from the VNFD, other information + comes from the PaaS Service assets provided by the + NFVO to the VNFM, and other information is provided at + runtime information about the usage of the PaaS + Service. + type: object + required: + - id + - paasServiceId + - paasServiceType + - paasServiceRequestId + - paasServiceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceType: + description: > + The type of PaaS Service. The value of this + attribute is expected to be matched against values + of the registered PaaS Services in the PSR. + type: string + paasServiceVersion: + description: | + A version. + type: string + paasServiceRequestId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + paasServiceHandle: + description: > + This type provides information enabling the access + and use of the PaaS Service by the VNF instance. + The type and format of the handle depends on the + form that the PaaS Service is formed. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + extra: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + indicators: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + instantiate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + terminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + heal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + operate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + createSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + revertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeCurrentVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperationLinks: + description: > + Links to the most recent LCM operation occurrences related + to this resource. See note 9. + type: object + properties: + recentVnfLcmOperation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmInstantiation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmTerminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmHeal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmModifyInfo: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmCreateSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmRevertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmSelectDplMods: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + VnfInstances.Post.201: + description: > + 201 CREATED + + Shall be returned when a new "Individual VNF Instance" resource and the + associated VNF instance identifier + + has been created successfully. The response body shall contain a + representation of the created VNF instance, + + as defined in clause 5.5.2.2. The HTTP response shall include a + "Location" HTTP header that contains the + + resource URI of the created VNF instance. + headers: + Version: + description: | + The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: | + The resource URI of the created VNF instance + style: simple + explode: false + schema: + type: string + format: url + content: + application/json: + schema: + description: "This type represents a VNF instance. * NOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist\n between the previous and the newly referred VNF package, i.e. when the new VNFD is\n changed with respect to the previous VNFD in other aspects than merely referencing\n to other VNF software images. In order to avoid misalignment of the VnfInstance with\n the current VNF's on-boarded VNF package, the values of attributes in the VnfInstance\n that have corresponding attributes in the VNFD shall be kept in sync with the values in the VNFD.\n* NOTE 2:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 3:\tThese attributes are sometimes also referred to as configuration parameters\n applicable to a VNF. Some of these are set prior to instantiation and cannot be modified\n if the VNF is instantiated, some are set prior to instantiation (are part of initial configuration)\n and can be modified later, and others can be set only after instantiation.\n The applicability of certain configuration may depend on the VNF and the required operation of\n the VNF at a certain point in time.\n* NOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child\n attributes of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared\n in the VNFD with a defined initial value. The defined initial values can be declared in the VNFD,\n and/or, in case of \"metadata\", obtained from the \"CreateVnfRequest\" structure. Child attributes of\n \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that have no defined initial value shall\n not be created, in order to be consistent with the semantics of the JSON Merge Patch method\n (see IETF RFC 7396) that interprets null values as deletion request.\n* NOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case\n of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding\n to the same VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc\n and externally-managed multi-site VL instance (refer to clause 5.5.3.5).\n* NOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity,\n they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n* NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual extCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the VNF \n LCM operation explicitly indicates the scale level for the aspect.\n* NOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n" + type: object + required: + - id + - vnfdId + - vnfProvider + - vnfProductName + - vnfSoftwareVersion + - vnfdVersion + - instantiationState + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfInstanceName: + description: > + Name of the VNF instance. This attribute can be modified with + the PATCH method. + type: string + vnfInstanceDescription: + description: > + Human-readable description of the VNF instance. This attribute + can be modified with the PATCH method. + type: string + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfProvider: + description: > + Provider of the VNF and the VNFD. The value is copied from the + VNFD. + type: string + vnfProductName: + description: > + Name to identify the VNF Product. The value is copied from the + VNFD. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + certificateInfo: + description: > + This type provides input information related to certificate + and certificate management. + type: object + required: + - id + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + certificateConfigurationInfo: + description: > + This type provides input information related to + certificate management. + type: object + required: + - securityPolicy + properties: + certificateBaseProfile: + description: > + This type provides input information to override + certificate base profile for certificate management + + NOTE : At least one overriding attributes shall be + present, otherwise shall be absent. + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + issuer: + type: string + description: Issuer of certificates. See note. + issuerUniqueIdentifier: + description: > + An identifier with the intention of being globally + unique. + type: string + subject: + description: > + This type provides input information related to + subject of certificate. + + * NOTE: At least one overriding attributes shall + be present, otherwise shall be absent. + type: object + properties: + commonName: + description: >- + Information of certification target subject + FQDN. See note. + type: string + organization: + description: >- + Information of certification target subject + Organization. See note. + type: string + country: + description: >- + Information of certification target subject + Country. See note. + type: string + state: + description: >- + Information of certification target subject + State. See note. + type: string + locality: + description: >- + Information of certification target subject + Locality. See note. + type: string + emailAddress: + description: >- + Information of certification contact email + address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of being globally + unique. + type: string + basicConstraints: + type: string + description: | + Basic constraints of certificates. See note. + issuerAltName: + description: >- + Alternative name of issuer of certificates in this + NS. See note. + type: array + items: + type: string + subjectAltName: + description: >- + Alternative name of subject of certificates. Shall + be present when this certificate is used for + encrypted communication using IP address and + subjectAltName attribute of CertificateBaseProfile + in CertificateDesc of VNFD is empty (see ETSI GS + NFV-IFA 011 [7],clause 7.1.19.4). See note + type: array + items: + type: string + nameConstraints: + description: Name constraints of certificates. See note. + type: array + items: + type: string + securityPolicy: + description: > + Information for security policy to be satisfied for + certificate. + type: array + items: + description: > + This type provides input information related to + security policy for certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + maxValidityPeriod: + description: Allowed max validity period for certificates. + type: integer + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: integer + delegationSupportedCertificateManagements: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + cmfInfo: + description: > + This type provides input information related to CMF + for certificate management. + type: object + required: + - id + - endPoint + - supportedProtocol + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + endPoint: + description: End point of CMF instance. + type: object + required: + - ipAddress + - link + properties: + 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 + link: + description: > + This type represents a link to a resource + using an absolute URI. + type: object + required: + - href + properties: + href: + description: > + String formatted according to IETF RFC + 3986. + type: string + supportedProtocols: + description: Supported protocol by CMF instance. + type: array + items: + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + certificateChain: + description: Certificate chain that this CMF provides. + type: array + items: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + certificateContents: + description: > + Information for contents of issued certificates. The + information contained in this attribute may be updated + over time during the VNF LCM, e.g. certificate(s) renewal. + type: array + items: + description: > + This type provides input information related to + certificate content. + type: object + required: + - id + - certificateDescId + - certificateType + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + certficateDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + certificateType: + description: Type of this certificate. + type: string + enum: + - VNFCI_CERT + - VNFOAM_CERT + supportedCertificateManagements: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + version: + description: | + A version. + type: string + serialNumber: + description: Serial number of this certificate. + type: integer + signatureAlgorithm: + description: Algorithm of this certificate's signature. + type: string + issuer: + description: Issuer of this certificate. + type: string + notBefore: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + notAfter: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + subject: + description: Subject of this certificate. + type: string + publicKeyAlgorithm: + description: Algorithm of this certificate's public key. + type: string + publicKey: + description: Public key of this certificate. + type: string + certificateExtensions: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + instantiationState: + description: | + The instantiation state of the VNF. + type: string + enum: + - NOT_INSTANTIATED + - INSTANTIATED + instantiatedVnfInfo: + description: > + Information specific to an instantiated VNF instance. This + attribute shall be present if the instantiateState attribute + value is INSTANTIATED. + type: object + required: + - flavourId + - vnfState + - extCpInfo + properties: + flavourId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfState: + description: > + STARTED: The VNF instance is up and running. STOPPED: The + VNF instance has been shut down. + type: string + enum: + - STARTED + - STOPPED + vnfPowerState: + description: > + This type represents information about the power state of + a VNF instance. + type: object + required: + - powerProfileId + - name + properties: + powerProfileId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + name: + description: | + Name of the power profile as provided in the VNFD. + type: string + powerConsumptionInfo: + description: > + This type represents information about estimated power + consumption of the resources associated with the power + profile, as provided in the VNFD. + type: object + required: + - minPowerConsumption + - maxPowerConsumption + - averagePowerConsumption + properties: + minPowerConsumption: + description: > + Minimum power consumption of this power profile. + Unit is KW/h. + type: integer + maxPowerConsumption: + description: > + Maximum power consumption of this power profile. + Unit is KW/h. + type: integer + averagePowerConsumption: + description: > + Average power consumption of this power profile. + Unit is KW/h. + type: integer + scaleStatus: + description: > + Scale status of the VNF, one entry per aspect. Represents + for every scaling aspect how "big" the VNF has been scaled + w.r.t. that aspect. This attribute shall be present if the + VNF supports scaling. See clause B.2 for an explanation of + VNF scaling. For an aspect that has not been deployed + because the related deployableModule has not been + selected, it indicates the scale level that has been + requested in the instantiation or in a scaling operation, + or, if none has been requested in any of them, the scale + level applicable to the aspect based on the default + instantiation level. See note 8. + type: array + items: + description: > + This type represents the scale level of a VNF instance + related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + scaleLevel: + description: > + Indicates the scale level. The minimum value shall + be 0 and the maximum value shall be <= maxScaleLevel + as described in the VNFD. + type: integer + maxScaleLevels: + description: > + Maximum allowed scale levels of the VNF, one entry per + aspect. This attribute shall be present if the VNF + supports scaling. + type: array + items: + description: > + This type represents the scale level of a VNF instance + related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + scaleLevel: + description: > + Indicates the scale level. The minimum value shall + be 0 and the maximum value shall be <= maxScaleLevel + as described in the VNFD. + type: integer + selectedDeployableModule: + description: > + References a currently selected deployable module, as + defined in the VNFD, that has already completed the + instantiation of its VNFCs + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + resourceCapacityDefinition: + description: > + Shows current values of VDU attributes related to resource + capacity, if different to the default values from the + VNFD, as indicated in the (one or more) request(s) of all + completed VNF LCM operation(s) that contain this + attribute. If an attribute value has been modified + multiple times, only the last value is shown. The values + indicated in this attribute are applicable to all VNFC + instances based on the VDU to which the + resourceCapacityDefinition is related. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes. + + * NOTE: Resource definitions not related to a VDU are + not considered in this version of the present document. + type: object + required: + - type + properties: + tag: + description: >- + Tag assigned by the issuer of a VNF LCM operation + request that contains this data type with values to + be applied to a VDU. It is used for tracking + purposes. The tag is preserved in the run time + record as long as at least one value of the capacity + related attributes associated with that tag is still + valid, i.e., it has not been modified by a later VNF + LCM operation request. At most one tag can be + included when the data type is used in a VNF LCM + operation request. When the data type is used in the + VnfInstance data type it may contain multiple tags, + namely those provided in VNF LCM requests, if at + least one of the values provided in that request + associated to that tag is still applicable in the + VNFCs created from this VDU, i.e., it has not been + modified by a later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: "Type of the resource definition referenced. VALUES •\tCOMPUTE •\tSTORAGE •\tOSCONTAINER" + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + osContainerDescData: + description: >- + Indicates values for resource capacity related + attributes in an OsContainerDesc. It shall be + present when the attribute ‘type’ indicates + OSCONTAINER and absent otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of an OsContainer resource. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for the + container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for the + container expressed in the same units as + specified in the + requested_memory_resources_valid_values + property in VNFD for this container + descriptor. See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources of the + type indicated in the key. The key is a string + that identifies an extended resource indicated + in the extended_resource_requests property in + the VNFD for this container descriptor. The + value is an integer that indicates the + required amount for a particular extended + resource.See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container can + maximally use in milli-CPU. See note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required for all + the hugepages of the size indicated in the + key. The key is a string and corresponds to + one of the values of the hugepage sizes + indicated in the huge_pages_resources + property in the VNFD for this container + descriptor. The value is a number that + indicates the required total size expressed in + the same units as in the + huge_pages_resources_property in the VNFD that + indicates the valid values for required total + size for the particular hugepage size. See + note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or + OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores + are requested to be allocated to logical + CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states of + virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual compute + resource of a VM. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - resourceTemplateId + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required for all + the hugepages of the size indicated in the key. + The key is a string and corresponds to one of + the values of the hugepage sizes indicated in + the huge_pages_requirements property in the VNFD + for this virtual compute descriptor. The value + is a number that indicates the required total + size expressed in the same units as in the + huge_pages_requirements property in the VNFD + that indicates the valid values for required + total size for the particular hugepage size. See + note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores + are requested to be allocated to logical CPU + cores according to the + cpuOperationalPowerStates attribute. In case + of "DYNAMIC", the CPU power states of + virtual CPU cores can be allocated to + logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size related + attribute in an VirtualStorageDesc. It shall be + present when the attribute 'type' indicates STORAGE + and absent otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual storage + resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + extCpInfo: + description: > + Information about the external CPs exposed by the VNF + instance. When trunking is enabled, the list of entries + includes both, external CPs corresponding to parent ports + of a trunk, and external CPs associated to sub-ports of a + trunk. See note 7. + type: array + minItems: 1 + items: + description: "This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n" + type: object + required: + - id + - cpdId + - cpConfigId + - cpProtocolInfo + oneOf: + - required: + - associatedVnfcCpId + - required: + - associatedVipCpId + - required: + - associatedVnfVirtualLinkId + properties: + id: + 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 + cpConfigId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + cpProtocolInfo: + description: | + Network protocol information for this CP. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and protocol(s) + associated to the network address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned to a + virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and + been associated to the CP. + type: array + items: + type: string + extLinkPortId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + associatedVnfcCpId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + associatedVipCpId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + associatedVirtualCpId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + associatedVnfVirtualLinkId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceInfo” structure + that provides the specification of the interface to + attach the connection point to a secondary container + cluster network. See notes 3 and 4. It shall be + present if the external CP is associated to a VNFC + realized by one or a set of OS containers and is + connected to a secondary container cluster network. + It shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + certificateContentId: + description: > + An identifier with the intention of being globally + unique. + type: string + cpSecurityGroupInfo: + description: > + This type provides the list of active security group + rules applied to an external CP instance. The type + identifies which "SecurityGroupRule" specified in + the VNFD are activated and the values of its + attributes. + type: object + required: + - securityGroupRuleId + - etherType + - protocol + - portRangeMin + - portRangeMax + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + description: + description: > + Human readable description of the security group + rule. + type: string + etherType: + description: > + Indicates the protocol carried over the Ethernet + layer. Permitted values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + protocol: + description: > + Indicates the protocol carried over the IP + layer. Permitted values: any protocol defined in + the IANA protocol registry (refer to clause + 9.10.1.2 ofd ETSI GS NFV-SOL 001 for further + information). + type: string + portRangeMin: + description: > + Value for the minimum port number in the range + that is matched by the security group rule. + type: integer + portRangeMax: + description: > + Value for the maximum port number in the range + that is matched by the security group rule. + type: integer + vipCpInfo: + description: > + VIP CPs that are part of the VNF instance. Shall be + present when that particular VIP CP of the VNFC instance + is associated to an external CP of the VNF instance. + + May be present otherwise. + type: array + items: + description: "This type provides information related to virtual IP CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n" + type: object + required: + - cpInstanceId + - cpdId + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There shall be one + cpProtocolInfo for layer 3. There may be one + cpProtocolInfo for layer 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and protocol(s) + associated to the network address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned to a + virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and + been associated to the CP. + type: array + items: + type: string + associatedVnfcCpIds: + description: > + Identifiers of the VnfcCps that share the virtual IP + address allocated to the VIP CP instance. See note. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + virtualCpInfo: + description: > + Virtual CPs that are part of the VNF instance. Shall be + present when a particular virtual CP is associated to an + external CP of the VNF instance. May be present otherwise. + type: array + items: + description: > + This type provides information related to a virtual CP + instance of a VNF. + + * NOTE 1: A consumer of the VNF LCM interface can learn + the actual VNFC instances implementing the service + accessible via the virtual CP instance by querying the "vnfcResourceInfo" from the "InstantiatedVnfInfo" + and filtering by corresponding "vduIds" values. + * NOTE 2: The information can be omitted because it is + already available as part of the external CP information + in the + VnfExtCpInfo structure. + type: object + required: + - cpInstanceId + - cpdId + - resourceHandle + - vduIds + properties: + cpInstanceId: + 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 + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There shall be one + cpProtocolInfo for each layer protocol supported. + This attribute may be omitted if the virtual CP is + exposed as an external CP. See note 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and protocol(s) + associated to the network address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned to a + virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and + been associated to the CP. + type: array + items: + type: string + vduIds: + description: > + Reference to the VDU(s) which implement the service + accessible via the virtual CP instance. See note. + type: array + minItems: 1 + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + additionalServiceInfo: + description: > + Additional service identification information of the + virtual CP instance. + type: array + items: + description: > + This type provides additional service information + of the virtual CP instance used to expose + properties of the virtual CP to NFV-MANO. + + NOTE: This attribute shall only be present if + additional information is needed to identify the + service + termination within the VNF, such as for example a URL path information in an HTTP request required + to allow a single virtual CP IP address to be used for several HTTP based services that use the + same port number. + type: object + required: + - portInfo + properties: + portInfo: + description: > + Service port numbers exposed by the virtual CP + instance. + minItems: 1 + type: array + items: + description: > + This type describes the service identifying + port properties exposed by the virtual CP + instance. + type: object + required: + - name + - port + - portConfigurable + properties: + name: + description: > + The name of the port exposed by the + virtual CP instance. + type: string + protocol: + description: > + The L4 protocol for this port exposed by + the virtual CP instance. + + Permitted values: - TCP - UDP - SCTP + type: string + enum: + - TCP + - UDP + - SCTP + port: + description: > + The L4 port number exposed by the + virtual CP instance. + type: integer + portConfigurable: + description: > + The Boolean is a data type having two + values (true and false). + type: boolean + serviceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + extVirtualLinkInfo: + description: > + Information about the external VLs the VNF instance is + connected to. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. Information about + the resource is available from the VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource provider. + See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available from + the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be present + if the resource is managed by a CISM and + it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the current CP + configuration information for the connection of + external CPs to the external virtual link. See + note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be + configured on the CP instances created from + the respective CPD. The key of the map which + identifies the individual VnfExtCpConfig + entries is of type "IdentifierInVnf" and is + managed by the NFVO. The entries shall be + applied by the VNFM according to the rules of + JSON Merge Patch (see IETF RFC 7396). See + notes 2, 3, 4, 5 and 6. In case of deleting an + external CP, the list of instances to be + deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided + link port, or a network attachment + definition resource of secondary container + cluster network, or network address + information per instance of an external + connection point. In the case of VM-based + deployment of the VNFC exposing the external + CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of + the VNFC exposing the external CP, the VNFM + shall use the network attachment definition + resource of secondary container cluster + network when connecting the CP to the + external VL. + + * NOTE 1: The following conditions apply to + the attributes "linkPortId" and + "cpProtocolData" for an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to + the attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more + than one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of + being globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create + a dedicated link port for the external + CP. If set to True, the VNFM shall + create a link port. If set to False, the + VNFM shall not create a link port. This + attribute is only applicable for + external CP instances without a floating + IP address that expose a VIP CP instance + for which a dedicated IP address is + allocated. It shall be present in that + case and shall be absent otherwise. + type: boolean + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects + the CP to a VL and the domain names for + the external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the + CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored. + + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security + groups. The parameters identify which + "SecurityGroupRule" specified in the + VNFD is activated/deactivated and for an + activated security group rule the values + of attributes defined in the VNFD that + can be overriden such as "portRangeMin" + and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceData” structure that + provides the specification of the + interface to attach the external CP to a + secondary container cluster network. It + is only applicable if the external CP is + connected or to be connected to a + secondary container cluster network. It + shall not be present if the external CP + is related to a virtual network not + categorized as secondary container + cluster network. See notes 2, 3 and 4. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + extNetAttDefResource: + description: > + Network attachment definition resources that provide + the specification of the interface to attach + connection points to this VL. + type: array + items: + description: > + This type contains information related to a + network attachment definition resource that + provides the specification of the interface used + to connect one or multiple connection points to a + secondary container cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of being + globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. Information about + the resource is available from the VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource provider. + See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available from + the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be present + if the resource is managed by a CISM and + it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated to + this network attachment definition resource. + Shall be present when the network attachment + definition resource is used for external + connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to this + network attachment definition resource. May be + present when the network attachment + definition resource is used for internal + connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + routingResource: + description: > + Network resources that provide the + forwarding/routing capabilities associated to the + network resource realizing this VL. + type: array + items: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + extManagedVirtualLinkInfo: + description: > + Information about the externally managed internal VLs of + the VNF instance. See note 5 and note 6. It is possible to + have several ExtManagedVirtualLinkInfo for the same VNF + internal VL in case of a multi-site VNF spanning several + VIMs. The set of ExtManagedVirtualLinkInfo corresponding + to the same VNF internal VL shall indicate so by + referencing to the same VnfVirtualLinkDesc and + externally-managed multi-site VL instance (refer to clause + 5.5.3.5). Even though externally-managed internal VLs are + also used for VNF-internal connectivity, they shall not be + listed in the "vnfVirtualLinkResourceInfo" attribute as + this would be redundant. + type: array + items: + description: > + This type provides information about an + externally-managed virtual link. *NOTE: Both vnfLinkPort + and vnfNetAttDefResource can be present in an + ExtManagedVirtualLinkInfo to indicate that + a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + vnfLinkPorts: + description: | + Link ports of this VL.See note. + type: array + items: + description: > + This type represents a link port of an internal VL + of a VNF. + + NOTE 1: Either cpInstanceId with cpInstanceType + set to "EXT_CP" or any combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides + examples for configurations where both + vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is scoped + by the value of "vimConnectionId" in the + "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. Information about + the resource is available from the VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource provider. + See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available from + the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be present + if the resource is managed by a CISM and + it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vnfNetAttDefResource: + description: > + Network attachment definition resources that provide + the specification of the interface to attach + connection points to this VL. + type: array + items: + description: > + This type contains information related to a + network attachment definition resource that + provides the specification of the interface used + to connect one or multiple connection points to a + secondary container cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of being + globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. Information about + the resource is available from the VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource provider. + See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available from + the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be present + if the resource is managed by a CISM and + it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated to + this network attachment definition resource. + Shall be present when the network attachment + definition resource is used for external + connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to this + network attachment definition resource. May be + present when the network attachment + definition resource is used for internal + connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + routingResource: + description: > + Network resources that provide the + forwarding/routing capabilities associated to the + network resource realizing this VL. + type: array + items: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + monitoringParameters: + description: | + Active monitoring parameters. + type: array + items: + type: object + required: + - id + - performanceMetric + properties: + id: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + name: + description: > + Human readable name of the monitoring parameter, as + defined in the VNFD. + type: string + performanceMetric: + description: > + Performance metric that is monitored. This attribute + shall contain the related "Measurement Name" value + as defined in clause 7.2 of ETSI GS NFV-IFA 027. + type: string + localizationLanguage: + description: > + Information about localization language of the VNF + (includes e.g. strings in the VNFD). The localization + languages supported by a VNF can be declared in the VNFD, + and localization language selection can take place at + instantiation time. The value shall comply with the format + defined in IETF RFC 5646. + type: string + vnfcResourceInfo: + description: > + Information about the virtualised compute and storage + resources used by the VNFCs of the VNF instance. + type: array + items: + description: "This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure \n of information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n - For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n - For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\n\n* NOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an internal VL that\n exposes an external CP. A VNFC CP is \"exposed as\" an external CP if it is connected directly\n to an external VL.\n* NOTE 3:\tThe information can be omitted because it is already available as part of the external CP information. * NOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\" structure by \n an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVnfc\"\n structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to \n this LCM operation occurrence.\n* NOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment \n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build \n a link redundant mated pair in SR-IOV cases.\n* NOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. * NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n" + type: object + required: + - id + - vduId + - computeResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + storageResourceIds: + description: > + References to the VirtualStorage resources or + references to Storage MCIO(s). The value refers to + a VirtualStorageResourceInfo item in the + VnfInstance. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfcCpInfo: + description: | + All the CPs of the VNFC instance. See note 7. + type: array + items: + type: object + required: + - id + - cpdId + properties: + id: + 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 + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + cpProtocolInfo: + description: > + Network protocol information for this CP. May + be omitted if the VNFC CP is exposed as an + external CP. The information can be omitted + because it is already available as part of the + external CP information. See note 3. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + parentCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceInfo” + structure that provides the specification of + the interface to attach the connection point + to a secondary container cluster network. See + notes 5 and 6. It shall be present if the + internal CP is associated to a VNFC realized + by one or a set of OS containers and is + connected to a secondary container cluster + network. It shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of the + certificate(s) that this VNFC CP instance + uses. Shall be present when using in + delegation-mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate management + is applicable. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" structure + that provides the information of the certificate(s) + that this VNFC CP instance uses. Shall be present + when using in delegation-mode. Otherwise shall not + be present. This attribute shall be supported when + delegation mode in certificate management is + applicable. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfVirtualLinkResourceInfo: + description: > + Information about the virtualised network resources used + by the VLs of the VNF instance. See note 6. Even though + externally-managed internal VLs are also used for + VNF-internal connectivity, they shall not be listed in the + "vnfVirtualLinkResourceInfo" attribute as this would be + redundant. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used by an + internal VL instance in a VNF instance. NOTE: If only + the value or the presence of this attribute is changed + in the "VnfVirtualLinkResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires including a + related "AffectedVirtualLink" structure in the VNF LCM operation occurrence notifications or the + "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + - vnfLinkPorts + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + reservationId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfLinkPorts: + description: > + Links ports of this VL. Shall be present when the + linkPort is used for external connectivity by the + VNF (refer to VnfLinkPortInfo). May be present + otherwise. + type: array + items: + description: > + This type represents a link port of an internal VL + of a VNF. + + NOTE 1: Either cpInstanceId with cpInstanceType + set to "EXT_CP" or any combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides + examples for configurations where both + vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is scoped + by the value of "vimConnectionId" in the + "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. Information about + the resource is available from the VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource provider. + See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available from + the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be present + if the resource is managed by a CISM and + it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + virtualStorageResourceInfo: + description: > + Information on the virtualised storage resource(s) used as + storage for the VNF instance. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. + + NOTE: If only the value or the presence of this + attribute is changed in the "VirtualStorageResourceInfo" + structure by an LCM operation occurrence, this does not + represent a change that requires including a related + "AffectedVirtualStorage" structure in the VNF LCM + operation occurrence notifications or the "VnfLcmOpOcc" + structure related to this LCM operation occurrence. + type: object + required: + - id + - virtualStorageDescId + - storageResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + reservationId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + vnfcInfo: + description: | + Information about the VNFC instances. + type: array + items: + description: "This type represents the information about a VNFC instance that is part of a VNF instance. * NOTE:\tThis allows to represent the error condition that a VNFC instance has lost its resources.\n" + type: object + required: + - id + - vduId + - vnfcState + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vduId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfcResourceInfoId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfcState: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfcConfigurableProperties: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + mcioInfo: + description: > + Information on the MCIO(s) representing VNFC instance(s) + realized by one or a set of OS containers and created + from the same VDU for the VNF instance. + type: array + items: + description: > + This type provides information about an MCIO + representing the set of VNFC instances realized by one + or a set of OS containers which have been created based + on the same VDU. Within the CISM, an MCIO controller + monitors the actual state of an MCIO representing the + set of VNFC instances realized by one or a set of OS + containers and compare it to the desired state. For an + MCIO related to a VDU that has the attribute + "isNumOfInstancesClusterBased" set to FALSE the desired + state is specified in the respective declarative + descriptor. For an MCIO related to a VDU that has the + attribute "isNumOfInstancesClusterBased" set to TRUE, + the desired state is determined by the number of + CIS-nodes in the cluster that fulfil the VDU + requirements. It triggers actions toward the CIS to + align the actual to the desired state. Monitoring the + actual state includes monitoring the number of MCIO + instances available at any specific point in time. In + addition, an MCIO controller maintains properties and + runtime information on the MCIO instances which have + been created based on the same VDU. The McioInfo data + structure provides the runtime information on the MCIOs + obtained from the MCIO controller. + + NOTE: There are different types of MCIOs. The set of + VNFC instances based on the same VDU is represented + by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type + of MCIO, e.g. a POD. + + Runtime information of the set of OS containers + realizing an individual VNFC instance is not part of + the McioInfo data structure; such runtime information + is provided in the ResourceHandle data structure + referenced from the VnfcResourceInfo. The McioInfo does + not provide runtime information of a constituent VNFC + instance created based on a specific VDU. + + NOTE 1: The type of MCIO as specified in the declarative + descriptor of the MCIO, and that can be read from + the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the + “kind” property of the declarative descriptor. + NOTE 2: If the attribute additionalInfo is present, it + may contain runtime information on the actual and + desired state of the MCIO(s). + NOTE 3: When the container infrastructure service is a + Kubernetes® instance, the mcioId is the combined + values from the kind and name fields of the Kubernetes resource object, separated by a slash. + Example: "Deployment/abcd". + NOTE 4: When the container infrastructure service is a + Kubernetes® instance, the mcioName is the name + field of the resource object. + type: object + required: + - mcioId + - mcioName + - mcioNamespace + - vduId + - cismId + - mcioType + - desiredInstances + - availableInstances + properties: + mcioId: + description: > + An identifier with the intention of being globally + unique. + type: string + mcioName: + description: | + Human readable name of this MCIO. See note 4. + type: string + mcioNamespace: + description: | + Namespace of this MCIO. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cismId: + description: > + An identifier with the intention of being globally + unique. + type: string + mcioType: + description: > + The type of MCIO. Specific values, their semantics + and associated MCIO types are defined in clause + 5.5.4.9. Additional values are also permitted. See + note 1. + type: string + enum: + - Deployment + - StatefulSet + - DaemonSet + desiredInstances: + description: | + Number of desired MCIO instances. + type: integer + availableInstances: + description: | + Number of available MCIO instances. + type: integer + additionalInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + certificateContentId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfPaasServiceInfo: + description: > + Information on the PaaS Services assigned and used by the + VNF instance. + type: array + items: + description: > + This type provides information about a PaaS Service that + is used by a VNF instance. The PaasServiceInfo is + comprised of various sets of information. Some + information comes from the VNFD, other information comes + from the PaaS Service assets provided by the NFVO to the + VNFM, and other information is provided at runtime + information about the usage of the PaaS Service. + type: object + required: + - id + - paasServiceId + - paasServiceType + - paasServiceRequestId + - paasServiceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceType: + description: > + The type of PaaS Service. The value of this + attribute is expected to be matched against values + of the registered PaaS Services in the PSR. + type: string + paasServiceVersion: + description: | + A version. + type: string + paasServiceRequestId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + paasServiceHandle: + description: > + This type provides information enabling the access + and use of the PaaS Service by the VNF instance. + The type and format of the handle depends on the + form that the PaaS Service is formed. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + additionalInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + indicators: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + instantiate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + terminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + heal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + operate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + createSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + revertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeCurrentVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperationLinks: + description: > + Links to the most recent LCM operation occurrences related to + this resource. See note 9. + type: object + properties: + recentVnfLcmOperation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmInstantiation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmTerminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmHeal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmModifyInfo: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmCreateSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmRevertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmSelectDplMods: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + VnfInstances.Post.422: + description: > + 422 Unprocessable Content + + + Shall be returned upon the following error: The content type of the + message content is supported and the + + message content of a request contains syntactically correct data but the + data cannot be processed. + + The general cause for this error and its handling is specified in clause + 6.4 of ETSI GS NFV-SOL 013, + + including rules for the presence of the response body. + + Specifically in case of this resource, the response code 422 shall also + be returned if the VNF package + + referenced by the "vnfdId" attribute in the "CreateVnfRequest" structure + is not in the "ENABLED" + + state or does not exist. In this case, the "detail" attribute in the + "ProblemDetails" structure shall convey + + more information about the error. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualVnfInstance.Get.200: + description: > + 200 OK + + Information about an individual VNF instance has been read successfully. + The response body shall contain a + + representation of the VNF instance, as defined in clause 5.5.2.2. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + ETag: + description: > + Used to provide the current entity-tag for the selected resource + representation. It can be sent in "200 OK", "201 Created" and "204 + No Content" responses. + style: simple + schema: + type: string + Last-Modified: + description: > + Used to provide a timestamp indicating the date and time at which + the server believes the selected resource representation was last + modified. It can be sent in "200 OK", "201 Created" and "204 No + Content" responses. + style: simple + schema: + type: string + format: date-time + content: + application/json: + schema: + description: "This type represents a VNF instance. * NOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist\n between the previous and the newly referred VNF package, i.e. when the new VNFD is\n changed with respect to the previous VNFD in other aspects than merely referencing\n to other VNF software images. In order to avoid misalignment of the VnfInstance with\n the current VNF's on-boarded VNF package, the values of attributes in the VnfInstance\n that have corresponding attributes in the VNFD shall be kept in sync with the values in the VNFD.\n* NOTE 2:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 3:\tThese attributes are sometimes also referred to as configuration parameters\n applicable to a VNF. Some of these are set prior to instantiation and cannot be modified\n if the VNF is instantiated, some are set prior to instantiation (are part of initial configuration)\n and can be modified later, and others can be set only after instantiation.\n The applicability of certain configuration may depend on the VNF and the required operation of\n the VNF at a certain point in time.\n* NOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child\n attributes of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared\n in the VNFD with a defined initial value. The defined initial values can be declared in the VNFD,\n and/or, in case of \"metadata\", obtained from the \"CreateVnfRequest\" structure. Child attributes of\n \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that have no defined initial value shall\n not be created, in order to be consistent with the semantics of the JSON Merge Patch method\n (see IETF RFC 7396) that interprets null values as deletion request.\n* NOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case\n of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding\n to the same VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc\n and externally-managed multi-site VL instance (refer to clause 5.5.3.5).\n* NOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity,\n they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n* NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual extCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the VNF \n LCM operation explicitly indicates the scale level for the aspect.\n* NOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n" + type: object + required: + - id + - vnfdId + - vnfProvider + - vnfProductName + - vnfSoftwareVersion + - vnfdVersion + - instantiationState + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfInstanceName: + description: > + Name of the VNF instance. This attribute can be modified with + the PATCH method. + type: string + vnfInstanceDescription: + description: > + Human-readable description of the VNF instance. This attribute + can be modified with the PATCH method. + type: string + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfProvider: + description: > + Provider of the VNF and the VNFD. The value is copied from the + VNFD. + type: string + vnfProductName: + description: > + Name to identify the VNF Product. The value is copied from the + VNFD. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + certificateInfo: + description: > + This type provides input information related to certificate + and certificate management. + type: object + required: + - id + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + certificateConfigurationInfo: + description: > + This type provides input information related to + certificate management. + type: object + required: + - securityPolicy + properties: + certificateBaseProfile: + description: > + This type provides input information to override + certificate base profile for certificate management + + NOTE : At least one overriding attributes shall be + present, otherwise shall be absent. + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + issuer: + type: string + description: Issuer of certificates. See note. + issuerUniqueIdentifier: + description: > + An identifier with the intention of being globally + unique. + type: string + subject: + description: > + This type provides input information related to + subject of certificate. + + * NOTE: At least one overriding attributes shall + be present, otherwise shall be absent. + type: object + properties: + commonName: + description: >- + Information of certification target subject + FQDN. See note. + type: string + organization: + description: >- + Information of certification target subject + Organization. See note. + type: string + country: + description: >- + Information of certification target subject + Country. See note. + type: string + state: + description: >- + Information of certification target subject + State. See note. + type: string + locality: + description: >- + Information of certification target subject + Locality. See note. + type: string + emailAddress: + description: >- + Information of certification contact email + address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of being globally + unique. + type: string + basicConstraints: + type: string + description: | + Basic constraints of certificates. See note. + issuerAltName: + description: >- + Alternative name of issuer of certificates in this + NS. See note. + type: array + items: + type: string + subjectAltName: + description: >- + Alternative name of subject of certificates. Shall + be present when this certificate is used for + encrypted communication using IP address and + subjectAltName attribute of CertificateBaseProfile + in CertificateDesc of VNFD is empty (see ETSI GS + NFV-IFA 011 [7],clause 7.1.19.4). See note + type: array + items: + type: string + nameConstraints: + description: Name constraints of certificates. See note. + type: array + items: + type: string + securityPolicy: + description: > + Information for security policy to be satisfied for + certificate. + type: array + items: + description: > + This type provides input information related to + security policy for certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + maxValidityPeriod: + description: Allowed max validity period for certificates. + type: integer + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: integer + delegationSupportedCertificateManagements: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + cmfInfo: + description: > + This type provides input information related to CMF + for certificate management. + type: object + required: + - id + - endPoint + - supportedProtocol + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + endPoint: + description: End point of CMF instance. + type: object + required: + - ipAddress + - link + properties: + 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 + link: + description: > + This type represents a link to a resource + using an absolute URI. + type: object + required: + - href + properties: + href: + description: > + String formatted according to IETF RFC + 3986. + type: string + supportedProtocols: + description: Supported protocol by CMF instance. + type: array + items: + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + certificateChain: + description: Certificate chain that this CMF provides. + type: array + items: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + certificateContents: + description: > + Information for contents of issued certificates. The + information contained in this attribute may be updated + over time during the VNF LCM, e.g. certificate(s) renewal. + type: array + items: + description: > + This type provides input information related to + certificate content. + type: object + required: + - id + - certificateDescId + - certificateType + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + certficateDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + certificateType: + description: Type of this certificate. + type: string + enum: + - VNFCI_CERT + - VNFOAM_CERT + supportedCertificateManagements: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + version: + description: | + A version. + type: string + serialNumber: + description: Serial number of this certificate. + type: integer + signatureAlgorithm: + description: Algorithm of this certificate's signature. + type: string + issuer: + description: Issuer of this certificate. + type: string + notBefore: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + notAfter: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + subject: + description: Subject of this certificate. + type: string + publicKeyAlgorithm: + description: Algorithm of this certificate's public key. + type: string + publicKey: + description: Public key of this certificate. + type: string + certificateExtensions: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + instantiationState: + description: | + The instantiation state of the VNF. + type: string + enum: + - NOT_INSTANTIATED + - INSTANTIATED + instantiatedVnfInfo: + description: > + Information specific to an instantiated VNF instance. This + attribute shall be present if the instantiateState attribute + value is INSTANTIATED. + type: object + required: + - flavourId + - vnfState + - extCpInfo + properties: + flavourId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfState: + description: > + STARTED: The VNF instance is up and running. STOPPED: The + VNF instance has been shut down. + type: string + enum: + - STARTED + - STOPPED + vnfPowerState: + description: > + This type represents information about the power state of + a VNF instance. + type: object + required: + - powerProfileId + - name + properties: + powerProfileId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + name: + description: | + Name of the power profile as provided in the VNFD. + type: string + powerConsumptionInfo: + description: > + This type represents information about estimated power + consumption of the resources associated with the power + profile, as provided in the VNFD. + type: object + required: + - minPowerConsumption + - maxPowerConsumption + - averagePowerConsumption + properties: + minPowerConsumption: + description: > + Minimum power consumption of this power profile. + Unit is KW/h. + type: integer + maxPowerConsumption: + description: > + Maximum power consumption of this power profile. + Unit is KW/h. + type: integer + averagePowerConsumption: + description: > + Average power consumption of this power profile. + Unit is KW/h. + type: integer + scaleStatus: + description: > + Scale status of the VNF, one entry per aspect. Represents + for every scaling aspect how "big" the VNF has been scaled + w.r.t. that aspect. This attribute shall be present if the + VNF supports scaling. See clause B.2 for an explanation of + VNF scaling. For an aspect that has not been deployed + because the related deployableModule has not been + selected, it indicates the scale level that has been + requested in the instantiation or in a scaling operation, + or, if none has been requested in any of them, the scale + level applicable to the aspect based on the default + instantiation level. See note 8. + type: array + items: + description: > + This type represents the scale level of a VNF instance + related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + scaleLevel: + description: > + Indicates the scale level. The minimum value shall + be 0 and the maximum value shall be <= maxScaleLevel + as described in the VNFD. + type: integer + maxScaleLevels: + description: > + Maximum allowed scale levels of the VNF, one entry per + aspect. This attribute shall be present if the VNF + supports scaling. + type: array + items: + description: > + This type represents the scale level of a VNF instance + related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + scaleLevel: + description: > + Indicates the scale level. The minimum value shall + be 0 and the maximum value shall be <= maxScaleLevel + as described in the VNFD. + type: integer + selectedDeployableModule: + description: > + References a currently selected deployable module, as + defined in the VNFD, that has already completed the + instantiation of its VNFCs + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + resourceCapacityDefinition: + description: > + Shows current values of VDU attributes related to resource + capacity, if different to the default values from the + VNFD, as indicated in the (one or more) request(s) of all + completed VNF LCM operation(s) that contain this + attribute. If an attribute value has been modified + multiple times, only the last value is shown. The values + indicated in this attribute are applicable to all VNFC + instances based on the VDU to which the + resourceCapacityDefinition is related. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes. + + * NOTE: Resource definitions not related to a VDU are + not considered in this version of the present document. + type: object + required: + - type + properties: + tag: + description: >- + Tag assigned by the issuer of a VNF LCM operation + request that contains this data type with values to + be applied to a VDU. It is used for tracking + purposes. The tag is preserved in the run time + record as long as at least one value of the capacity + related attributes associated with that tag is still + valid, i.e., it has not been modified by a later VNF + LCM operation request. At most one tag can be + included when the data type is used in a VNF LCM + operation request. When the data type is used in the + VnfInstance data type it may contain multiple tags, + namely those provided in VNF LCM requests, if at + least one of the values provided in that request + associated to that tag is still applicable in the + VNFCs created from this VDU, i.e., it has not been + modified by a later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: "Type of the resource definition referenced. VALUES •\tCOMPUTE •\tSTORAGE •\tOSCONTAINER" + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + osContainerDescData: + description: >- + Indicates values for resource capacity related + attributes in an OsContainerDesc. It shall be + present when the attribute ‘type’ indicates + OSCONTAINER and absent otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of an OsContainer resource. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for the + container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for the + container expressed in the same units as + specified in the + requested_memory_resources_valid_values + property in VNFD for this container + descriptor. See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources of the + type indicated in the key. The key is a string + that identifies an extended resource indicated + in the extended_resource_requests property in + the VNFD for this container descriptor. The + value is an integer that indicates the + required amount for a particular extended + resource.See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container can + maximally use in milli-CPU. See note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required for all + the hugepages of the size indicated in the + key. The key is a string and corresponds to + one of the values of the hugepage sizes + indicated in the huge_pages_resources + property in the VNFD for this container + descriptor. The value is a number that + indicates the required total size expressed in + the same units as in the + huge_pages_resources_property in the VNFD that + indicates the valid values for required total + size for the particular hugepage size. See + note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or + OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores + are requested to be allocated to logical + CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states of + virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual compute + resource of a VM. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - resourceTemplateId + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required for all + the hugepages of the size indicated in the key. + The key is a string and corresponds to one of + the values of the hugepage sizes indicated in + the huge_pages_requirements property in the VNFD + for this virtual compute descriptor. The value + is a number that indicates the required total + size expressed in the same units as in the + huge_pages_requirements property in the VNFD + that indicates the valid values for required + total size for the particular hugepage size. See + note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores + are requested to be allocated to logical CPU + cores according to the + cpuOperationalPowerStates attribute. In case + of "DYNAMIC", the CPU power states of + virtual CPU cores can be allocated to + logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size related + attribute in an VirtualStorageDesc. It shall be + present when the attribute 'type' indicates STORAGE + and absent otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual storage + resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + extCpInfo: + description: > + Information about the external CPs exposed by the VNF + instance. When trunking is enabled, the list of entries + includes both, external CPs corresponding to parent ports + of a trunk, and external CPs associated to sub-ports of a + trunk. See note 7. + type: array + minItems: 1 + items: + description: "This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n" + type: object + required: + - id + - cpdId + - cpConfigId + - cpProtocolInfo + oneOf: + - required: + - associatedVnfcCpId + - required: + - associatedVipCpId + - required: + - associatedVnfVirtualLinkId + properties: + id: + 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 + cpConfigId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + cpProtocolInfo: + description: | + Network protocol information for this CP. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and protocol(s) + associated to the network address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned to a + virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and + been associated to the CP. + type: array + items: + type: string + extLinkPortId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + associatedVnfcCpId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + associatedVipCpId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + associatedVirtualCpId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + associatedVnfVirtualLinkId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceInfo” structure + that provides the specification of the interface to + attach the connection point to a secondary container + cluster network. See notes 3 and 4. It shall be + present if the external CP is associated to a VNFC + realized by one or a set of OS containers and is + connected to a secondary container cluster network. + It shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + certificateContentId: + description: > + An identifier with the intention of being globally + unique. + type: string + cpSecurityGroupInfo: + description: > + This type provides the list of active security group + rules applied to an external CP instance. The type + identifies which "SecurityGroupRule" specified in + the VNFD are activated and the values of its + attributes. + type: object + required: + - securityGroupRuleId + - etherType + - protocol + - portRangeMin + - portRangeMax + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + description: + description: > + Human readable description of the security group + rule. + type: string + etherType: + description: > + Indicates the protocol carried over the Ethernet + layer. Permitted values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + protocol: + description: > + Indicates the protocol carried over the IP + layer. Permitted values: any protocol defined in + the IANA protocol registry (refer to clause + 9.10.1.2 ofd ETSI GS NFV-SOL 001 for further + information). + type: string + portRangeMin: + description: > + Value for the minimum port number in the range + that is matched by the security group rule. + type: integer + portRangeMax: + description: > + Value for the maximum port number in the range + that is matched by the security group rule. + type: integer + vipCpInfo: + description: > + VIP CPs that are part of the VNF instance. Shall be + present when that particular VIP CP of the VNFC instance + is associated to an external CP of the VNF instance. + + May be present otherwise. + type: array + items: + description: "This type provides information related to virtual IP CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n" + type: object + required: + - cpInstanceId + - cpdId + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There shall be one + cpProtocolInfo for layer 3. There may be one + cpProtocolInfo for layer 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and protocol(s) + associated to the network address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned to a + virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and + been associated to the CP. + type: array + items: + type: string + associatedVnfcCpIds: + description: > + Identifiers of the VnfcCps that share the virtual IP + address allocated to the VIP CP instance. See note. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + virtualCpInfo: + description: > + Virtual CPs that are part of the VNF instance. Shall be + present when a particular virtual CP is associated to an + external CP of the VNF instance. May be present otherwise. + type: array + items: + description: > + This type provides information related to a virtual CP + instance of a VNF. + + * NOTE 1: A consumer of the VNF LCM interface can learn + the actual VNFC instances implementing the service + accessible via the virtual CP instance by querying the "vnfcResourceInfo" from the "InstantiatedVnfInfo" + and filtering by corresponding "vduIds" values. + * NOTE 2: The information can be omitted because it is + already available as part of the external CP information + in the + VnfExtCpInfo structure. + type: object + required: + - cpInstanceId + - cpdId + - resourceHandle + - vduIds + properties: + cpInstanceId: + 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 + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There shall be one + cpProtocolInfo for each layer protocol supported. + This attribute may be omitted if the virtual CP is + exposed as an external CP. See note 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and protocol(s) + associated to the network address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned to a + virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and + been associated to the CP. + type: array + items: + type: string + vduIds: + description: > + Reference to the VDU(s) which implement the service + accessible via the virtual CP instance. See note. + type: array + minItems: 1 + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + additionalServiceInfo: + description: > + Additional service identification information of the + virtual CP instance. + type: array + items: + description: > + This type provides additional service information + of the virtual CP instance used to expose + properties of the virtual CP to NFV-MANO. + + NOTE: This attribute shall only be present if + additional information is needed to identify the + service + termination within the VNF, such as for example a URL path information in an HTTP request required + to allow a single virtual CP IP address to be used for several HTTP based services that use the + same port number. + type: object + required: + - portInfo + properties: + portInfo: + description: > + Service port numbers exposed by the virtual CP + instance. + minItems: 1 + type: array + items: + description: > + This type describes the service identifying + port properties exposed by the virtual CP + instance. + type: object + required: + - name + - port + - portConfigurable + properties: + name: + description: > + The name of the port exposed by the + virtual CP instance. + type: string + protocol: + description: > + The L4 protocol for this port exposed by + the virtual CP instance. + + Permitted values: - TCP - UDP - SCTP + type: string + enum: + - TCP + - UDP + - SCTP + port: + description: > + The L4 port number exposed by the + virtual CP instance. + type: integer + portConfigurable: + description: > + The Boolean is a data type having two + values (true and false). + type: boolean + serviceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + extVirtualLinkInfo: + description: > + Information about the external VLs the VNF instance is + connected to. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. Information about + the resource is available from the VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource provider. + See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available from + the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be present + if the resource is managed by a CISM and + it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the current CP + configuration information for the connection of + external CPs to the external virtual link. See + note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be + configured on the CP instances created from + the respective CPD. The key of the map which + identifies the individual VnfExtCpConfig + entries is of type "IdentifierInVnf" and is + managed by the NFVO. The entries shall be + applied by the VNFM according to the rules of + JSON Merge Patch (see IETF RFC 7396). See + notes 2, 3, 4, 5 and 6. In case of deleting an + external CP, the list of instances to be + deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided + link port, or a network attachment + definition resource of secondary container + cluster network, or network address + information per instance of an external + connection point. In the case of VM-based + deployment of the VNFC exposing the external + CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of + the VNFC exposing the external CP, the VNFM + shall use the network attachment definition + resource of secondary container cluster + network when connecting the CP to the + external VL. + + * NOTE 1: The following conditions apply to + the attributes "linkPortId" and + "cpProtocolData" for an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to + the attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more + than one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of + being globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create + a dedicated link port for the external + CP. If set to True, the VNFM shall + create a link port. If set to False, the + VNFM shall not create a link port. This + attribute is only applicable for + external CP instances without a floating + IP address that expose a VIP CP instance + for which a dedicated IP address is + allocated. It shall be present in that + case and shall be absent otherwise. + type: boolean + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects + the CP to a VL and the domain names for + the external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the + CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored. + + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security + groups. The parameters identify which + "SecurityGroupRule" specified in the + VNFD is activated/deactivated and for an + activated security group rule the values + of attributes defined in the VNFD that + can be overriden such as "portRangeMin" + and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceData” structure that + provides the specification of the + interface to attach the external CP to a + secondary container cluster network. It + is only applicable if the external CP is + connected or to be connected to a + secondary container cluster network. It + shall not be present if the external CP + is related to a virtual network not + categorized as secondary container + cluster network. See notes 2, 3 and 4. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + extNetAttDefResource: + description: > + Network attachment definition resources that provide + the specification of the interface to attach + connection points to this VL. + type: array + items: + description: > + This type contains information related to a + network attachment definition resource that + provides the specification of the interface used + to connect one or multiple connection points to a + secondary container cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of being + globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. Information about + the resource is available from the VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource provider. + See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available from + the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be present + if the resource is managed by a CISM and + it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated to + this network attachment definition resource. + Shall be present when the network attachment + definition resource is used for external + connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to this + network attachment definition resource. May be + present when the network attachment + definition resource is used for internal + connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + routingResource: + description: > + Network resources that provide the + forwarding/routing capabilities associated to the + network resource realizing this VL. + type: array + items: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + extManagedVirtualLinkInfo: + description: > + Information about the externally managed internal VLs of + the VNF instance. See note 5 and note 6. It is possible to + have several ExtManagedVirtualLinkInfo for the same VNF + internal VL in case of a multi-site VNF spanning several + VIMs. The set of ExtManagedVirtualLinkInfo corresponding + to the same VNF internal VL shall indicate so by + referencing to the same VnfVirtualLinkDesc and + externally-managed multi-site VL instance (refer to clause + 5.5.3.5). Even though externally-managed internal VLs are + also used for VNF-internal connectivity, they shall not be + listed in the "vnfVirtualLinkResourceInfo" attribute as + this would be redundant. + type: array + items: + description: > + This type provides information about an + externally-managed virtual link. *NOTE: Both vnfLinkPort + and vnfNetAttDefResource can be present in an + ExtManagedVirtualLinkInfo to indicate that + a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + vnfLinkPorts: + description: | + Link ports of this VL.See note. + type: array + items: + description: > + This type represents a link port of an internal VL + of a VNF. + + NOTE 1: Either cpInstanceId with cpInstanceType + set to "EXT_CP" or any combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides + examples for configurations where both + vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is scoped + by the value of "vimConnectionId" in the + "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. Information about + the resource is available from the VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource provider. + See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available from + the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be present + if the resource is managed by a CISM and + it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vnfNetAttDefResource: + description: > + Network attachment definition resources that provide + the specification of the interface to attach + connection points to this VL. + type: array + items: + description: > + This type contains information related to a + network attachment definition resource that + provides the specification of the interface used + to connect one or multiple connection points to a + secondary container cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of being + globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. Information about + the resource is available from the VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource provider. + See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available from + the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be present + if the resource is managed by a CISM and + it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated to + this network attachment definition resource. + Shall be present when the network attachment + definition resource is used for external + connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to this + network attachment definition resource. May be + present when the network attachment + definition resource is used for internal + connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + routingResource: + description: > + Network resources that provide the + forwarding/routing capabilities associated to the + network resource realizing this VL. + type: array + items: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + monitoringParameters: + description: | + Active monitoring parameters. + type: array + items: + type: object + required: + - id + - performanceMetric + properties: + id: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + name: + description: > + Human readable name of the monitoring parameter, as + defined in the VNFD. + type: string + performanceMetric: + description: > + Performance metric that is monitored. This attribute + shall contain the related "Measurement Name" value + as defined in clause 7.2 of ETSI GS NFV-IFA 027. + type: string + localizationLanguage: + description: > + Information about localization language of the VNF + (includes e.g. strings in the VNFD). The localization + languages supported by a VNF can be declared in the VNFD, + and localization language selection can take place at + instantiation time. The value shall comply with the format + defined in IETF RFC 5646. + type: string + vnfcResourceInfo: + description: > + Information about the virtualised compute and storage + resources used by the VNFCs of the VNF instance. + type: array + items: + description: "This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure \n of information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n - For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n - For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\n\n* NOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an internal VL that\n exposes an external CP. A VNFC CP is \"exposed as\" an external CP if it is connected directly\n to an external VL.\n* NOTE 3:\tThe information can be omitted because it is already available as part of the external CP information. * NOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\" structure by \n an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVnfc\"\n structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to \n this LCM operation occurrence.\n* NOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment \n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build \n a link redundant mated pair in SR-IOV cases.\n* NOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. * NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n" + type: object + required: + - id + - vduId + - computeResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + storageResourceIds: + description: > + References to the VirtualStorage resources or + references to Storage MCIO(s). The value refers to + a VirtualStorageResourceInfo item in the + VnfInstance. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfcCpInfo: + description: | + All the CPs of the VNFC instance. See note 7. + type: array + items: + type: object + required: + - id + - cpdId + properties: + id: + 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 + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + cpProtocolInfo: + description: > + Network protocol information for this CP. May + be omitted if the VNFC CP is exposed as an + external CP. The information can be omitted + because it is already available as part of the + external CP information. See note 3. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + parentCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceInfo” + structure that provides the specification of + the interface to attach the connection point + to a secondary container cluster network. See + notes 5 and 6. It shall be present if the + internal CP is associated to a VNFC realized + by one or a set of OS containers and is + connected to a secondary container cluster + network. It shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of the + certificate(s) that this VNFC CP instance + uses. Shall be present when using in + delegation-mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate management + is applicable. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" structure + that provides the information of the certificate(s) + that this VNFC CP instance uses. Shall be present + when using in delegation-mode. Otherwise shall not + be present. This attribute shall be supported when + delegation mode in certificate management is + applicable. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfVirtualLinkResourceInfo: + description: > + Information about the virtualised network resources used + by the VLs of the VNF instance. See note 6. Even though + externally-managed internal VLs are also used for + VNF-internal connectivity, they shall not be listed in the + "vnfVirtualLinkResourceInfo" attribute as this would be + redundant. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used by an + internal VL instance in a VNF instance. NOTE: If only + the value or the presence of this attribute is changed + in the "VnfVirtualLinkResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires including a + related "AffectedVirtualLink" structure in the VNF LCM operation occurrence notifications or the + "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + - vnfLinkPorts + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + reservationId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfLinkPorts: + description: > + Links ports of this VL. Shall be present when the + linkPort is used for external connectivity by the + VNF (refer to VnfLinkPortInfo). May be present + otherwise. + type: array + items: + description: > + This type represents a link port of an internal VL + of a VNF. + + NOTE 1: Either cpInstanceId with cpInstanceType + set to "EXT_CP" or any combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides + examples for configurations where both + vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is scoped + by the value of "vimConnectionId" in the + "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. Information about + the resource is available from the VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource provider. + See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available from + the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be present + if the resource is managed by a CISM and + it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + virtualStorageResourceInfo: + description: > + Information on the virtualised storage resource(s) used as + storage for the VNF instance. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. + + NOTE: If only the value or the presence of this + attribute is changed in the "VirtualStorageResourceInfo" + structure by an LCM operation occurrence, this does not + represent a change that requires including a related + "AffectedVirtualStorage" structure in the VNF LCM + operation occurrence notifications or the "VnfLcmOpOcc" + structure related to this LCM operation occurrence. + type: object + required: + - id + - virtualStorageDescId + - storageResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + reservationId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + vnfcInfo: + description: | + Information about the VNFC instances. + type: array + items: + description: "This type represents the information about a VNFC instance that is part of a VNF instance. * NOTE:\tThis allows to represent the error condition that a VNFC instance has lost its resources.\n" + type: object + required: + - id + - vduId + - vnfcState + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vduId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfcResourceInfoId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfcState: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfcConfigurableProperties: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + mcioInfo: + description: > + Information on the MCIO(s) representing VNFC instance(s) + realized by one or a set of OS containers and created + from the same VDU for the VNF instance. + type: array + items: + description: > + This type provides information about an MCIO + representing the set of VNFC instances realized by one + or a set of OS containers which have been created based + on the same VDU. Within the CISM, an MCIO controller + monitors the actual state of an MCIO representing the + set of VNFC instances realized by one or a set of OS + containers and compare it to the desired state. For an + MCIO related to a VDU that has the attribute + "isNumOfInstancesClusterBased" set to FALSE the desired + state is specified in the respective declarative + descriptor. For an MCIO related to a VDU that has the + attribute "isNumOfInstancesClusterBased" set to TRUE, + the desired state is determined by the number of + CIS-nodes in the cluster that fulfil the VDU + requirements. It triggers actions toward the CIS to + align the actual to the desired state. Monitoring the + actual state includes monitoring the number of MCIO + instances available at any specific point in time. In + addition, an MCIO controller maintains properties and + runtime information on the MCIO instances which have + been created based on the same VDU. The McioInfo data + structure provides the runtime information on the MCIOs + obtained from the MCIO controller. + + NOTE: There are different types of MCIOs. The set of + VNFC instances based on the same VDU is represented + by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type + of MCIO, e.g. a POD. + + Runtime information of the set of OS containers + realizing an individual VNFC instance is not part of + the McioInfo data structure; such runtime information + is provided in the ResourceHandle data structure + referenced from the VnfcResourceInfo. The McioInfo does + not provide runtime information of a constituent VNFC + instance created based on a specific VDU. + + NOTE 1: The type of MCIO as specified in the declarative + descriptor of the MCIO, and that can be read from + the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the + “kind” property of the declarative descriptor. + NOTE 2: If the attribute additionalInfo is present, it + may contain runtime information on the actual and + desired state of the MCIO(s). + NOTE 3: When the container infrastructure service is a + Kubernetes® instance, the mcioId is the combined + values from the kind and name fields of the Kubernetes resource object, separated by a slash. + Example: "Deployment/abcd". + NOTE 4: When the container infrastructure service is a + Kubernetes® instance, the mcioName is the name + field of the resource object. + type: object + required: + - mcioId + - mcioName + - mcioNamespace + - vduId + - cismId + - mcioType + - desiredInstances + - availableInstances + properties: + mcioId: + description: > + An identifier with the intention of being globally + unique. + type: string + mcioName: + description: | + Human readable name of this MCIO. See note 4. + type: string + mcioNamespace: + description: | + Namespace of this MCIO. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cismId: + description: > + An identifier with the intention of being globally + unique. + type: string + mcioType: + description: > + The type of MCIO. Specific values, their semantics + and associated MCIO types are defined in clause + 5.5.4.9. Additional values are also permitted. See + note 1. + type: string + enum: + - Deployment + - StatefulSet + - DaemonSet + desiredInstances: + description: | + Number of desired MCIO instances. + type: integer + availableInstances: + description: | + Number of available MCIO instances. + type: integer + additionalInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + certificateContentId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfPaasServiceInfo: + description: > + Information on the PaaS Services assigned and used by the + VNF instance. + type: array + items: + description: > + This type provides information about a PaaS Service that + is used by a VNF instance. The PaasServiceInfo is + comprised of various sets of information. Some + information comes from the VNFD, other information comes + from the PaaS Service assets provided by the NFVO to the + VNFM, and other information is provided at runtime + information about the usage of the PaaS Service. + type: object + required: + - id + - paasServiceId + - paasServiceType + - paasServiceRequestId + - paasServiceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceType: + description: > + The type of PaaS Service. The value of this + attribute is expected to be matched against values + of the registered PaaS Services in the PSR. + type: string + paasServiceVersion: + description: | + A version. + type: string + paasServiceRequestId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + paasServiceHandle: + description: > + This type provides information enabling the access + and use of the PaaS Service by the VNF instance. + The type and format of the handle depends on the + form that the PaaS Service is formed. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + additionalInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + indicators: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + instantiate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + terminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + heal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + operate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + createSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + revertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeCurrentVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperationLinks: + description: > + Links to the most recent LCM operation occurrences related to + this resource. See note 9. + type: object + properties: + recentVnfLcmOperation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmInstantiation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmTerminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmHeal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmModifyInfo: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmCreateSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmRevertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmSelectDplMods: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualVnfInstance.Delete.204: + description: > + 204 NO CONTENT + + The "Individual VNF instance" resource and the associated VNF identifier + were deleted successfully. + + The response body shall be empty. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + This type represents a VNF identifier deletion notification, which + informs the receiver of the deletion of a new "Individual VNF + instance" resource and the associated VNF instance identifier. + This notification shall be triggered by the VNFM when it has + deleted an "Individual VNF instance" resource and the associated + VNF instance identifier. + type: object + required: + - id + - notificationType + - subscriptionId + - timeStamp + - vnfInstanceId + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall be + set to "VnfIdentifierDeletionNotification" for this + notification type. + type: string + enum: + - VnfIdentifierDeletionNotification + subscriptionId: + description: | + An identifier with the intention of being globally unique. + type: string + timeStamp: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + _links: + description: > + This type represents the links to resources that a + notification can contain. + type: object + required: + - vnfInstance + - subscription + properties: + vnfInstance: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + subscription: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfLcmOpOcc: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualVnfInstance.Delete.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that the "Individual + VNF instance" resource is in INSTANTIATED state. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualVnfInstance.Patch.202: + description: > + 202 ACCEPTED + + The request was accepted for processing, but the processing has not been + completed. On success, the HTTP + + response shall include a "Location" HTTP header that contains the URI of + the newly-created an "Individual + + VNF LCM operation occurrence" resource corresponding to the operation. + The response body shall be empty. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: > + Used in redirection, or when a new resource has been created. This + header field shall be present if the + + response status code is 201 or 3xx. In the present document this + header field is also used if the response + + status code is 202 and a new resource was created. + style: simple + explode: false + schema: + type: string + format: url + content: {} + IndividualVnfInstance.Patch.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the "Individual VNF instance" + resource + Typically, this is due to the fact that another LCM + operation is ongoing. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute should convey + more information about the error + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + InstantiateVnfInstance.Post.202: + description: > + 202 ACCEPTED + + The request has been accepted for processing, but the processing has not + been completed. The response body + + shall be empty. The HTTP response shall include a "Location" HTTP header + that contains the URI of the + + newly-created "VNF LCM operation occurrence" resource corresponding to + the operation. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: > + Used in redirection, or when a new resource has been created. This + header field shall be present if the + + response status code is 201 or 3xx. In the present document this + header field is also used if the response + + status code is 202 and a new resource was created. + style: simple + explode: false + schema: + type: string + format: url + content: {} + InstantiateVnfInstance.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that the "Individual + VNF instance" resource is in INSTANTIATED state + or that a required (see note) child attribute of the + "extensions" attribute has not been set. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + ScaleVnfInstance.Post.202: + description: > + 202 ACCEPTED + + The request has been accepted for processing, but the processing has not + been completed. The response body + + shall be empty. The HTTP response shall include a "Location" HTTP header + that contains the URI of the + + newly-created "Individual VNF LCM operation occurrence" resource + corresponding to the operation. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: > + Used in redirection, or when a new resource has been created. This + header field shall be present if the + + response status code is 201 or 3xx. In the present document this + header field is also used if the response + + status code is 202 and a new resource was created. + style: simple + explode: false + schema: + type: string + format: url + content: {} + ScaleVnfInstance.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that the "Individual + VNF instance" resource is in NOT_INSTANTIATED + state, that another lifecycle management operation is + ongoing, or that a required (see note) child attribute + of the "extensions" attribute has not been set. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + ScaleVnfInstanceToLevel.Post.202: + description: > + 202 ACCEPTED + + The request has been accepted for processing, but the processing has not + been completed. The response body shall + + be empty. The HTTP response shall include a "Location" HTTP header that + contains the URI of the newly-created + + "VNF LCM operation occurrence" resource corresponding to the operation. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: > + Used in redirection, or when a new resource has been created. This + header field shall be present if the + + response status code is 201 or 3xx. In the present document this + header field is also used if the response + + status code is 202 and a new resource was created. + style: simple + explode: false + schema: + type: string + format: url + content: {} + ScaleVnfInstanceToLevel.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that the VNF instance + resource is in NOT_INSTANTIATED state, that + another lifecycle management operation is ongoing, + or that a required (see note) child attribute of the + "extensions" attribute has not been set. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + Note: Required attributes are marked as "required" in the VNFD. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + VnfInstanceChangeFlavour.Post.202: + description: > + 202 ACCEPTED + + The request has been accepted for processing, but the processing has not + been completed. The response body + + shall be empty. The HTTP response shall include a "Location" HTTP header + that contains the URI of the + + newly-created "Individual VNF LCM operation occurrence" resource + corresponding to the operation. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: > + Used in redirection, or when a new resource has been created. This + header field shall be present if the + + response status code is 201 or 3xx. In the present document this + header field is also used if the response + + status code is 202 and a new resource was created. + style: simple + explode: false + schema: + type: string + format: url + content: {} + VnfInstanceChangeFlavour.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that the + "Individual VNF instance" resource is in + NOT_INSTANTIATED state, that another + lifecycle management operation is ongoing, or + that a required (see note) child attribute of the + "extensions" attribute has not been set. + The response body shall contain a + ProblemDetails structure, in which the "detail" + attribute shall convey more information about the + error. + note: Required attributes are marked as "required" in the VNFD. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + TerminateVnfInstance.Post.202: + description: > + 202 ACCEPTED + + The request has been accepted for processing. The response body shall be + empty. The HTTP response shall include + + a "Location" HTTP header that contains the URI of the newly-created + "Individual VNF LCM operation occurrence" + + resource corresponding to the operation. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: > + Used in redirection, or when a new resource has been created. This + header field shall be present if the + + response status code is 201 or 3xx. In the present document this + header field is also used if the response + + status code is 202 and a new resource was created. + style: simple + explode: false + schema: + type: string + format: url + content: {} + TerminateVnfInstance.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that the "Individual VNF + instance" resource is in NOT_INSTANTIATED state, or + that another lifecycle management operation is + ongoing, or that a required (see note) child attribute of + the "extensions" attribute has not been set. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + note: Required attributes are marked as "required" in the VNFD. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + HealVnfInstance.Post.202: + description: > + 202 ACCEPTED + + The request has been accepted for processing, but the processing has not + been completed. The response body + + shall be empty. The HTTP response shall include a "Location" HTTP header + that contains the URI of the + + newly-created "Individual VNF LCM operation occurrence" resource + corresponding to the operation. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: > + Used in redirection, or when a new resource has been created. This + header field shall be present if the + + response status code is 201 or 3xx. In the present document this + header field is also used if the response + + status code is 202 and a new resource was created. + style: simple + explode: false + schema: + type: string + format: url + content: {} + HealVnfInstance.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that the "Individual VNF + instance" resource is in NOT_INSTANTIATED state, + that another lifecycle management operation is + ongoing, or that a required (see note) child attribute of + the "extensions" attribute has not been set. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + note: Required attributes are marked as "required" in the VNFD. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + OperateVnfInstance.Post.202: + description: > + 202 ACCEPTED + + The request has been accepted for processing, but the processing has not + been completed. The response body + + shall be empty. The HTTP response shall include a "Location" HTTP header + that contains the URI of the + + newly-created "VNF LCM operation occurrence" resource corresponding to + the operation. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: > + Used in redirection, or when a new resource has been created. This + header field shall be present if the + + response status code is 201 or 3xx. In the present document this + header field is also used if the response + + status code is 202 and a new resource was created. + style: simple + explode: false + schema: + type: string + format: url + content: {} + OperateVnfInstance.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that the "Individual VNF + instance" resource is in NOT_INSTANTIATED state, + that another lifecycle management operation is + ongoing, or that a required (see note) child attribute of + the "extensions" attribute has not been set. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + note: Required attributes are marked as "required" in the VNFD. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + VnfInstanceChangeExtConn.Post.202: + description: > + 202 ACCEPTED + + The request has been accepted for processing, but the processing has not + been completed. The response body + + shall be empty. The HTTP response shall include a "Location" HTTP header + that contains the URI of the + + newly-created "VNF LCM operation occurrence" resource corresponding to + the operation. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: > + Used in redirection, or when a new resource has been created. This + header field shall be present if the + + response status code is 201 or 3xx. In the present document this + header field is also used if the response + + status code is 202 and a new resource was created. + style: simple + explode: false + schema: + type: string + format: url + content: {} + VnfInstanceChangeExtConn.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that another + lifecycle management operation is ongoing, or that + a required (see note) child attribute of the + "extensions" attribute has not been set. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + note: Required attributes are marked as "required" in the VNFD. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + VnfInstanceChangeVnfPkg.Post.202: + description: > + 202 ACCEPTED + + Shall be returned when the request has been accepted for processing. + + The response body shall be empty. The HTTP response shall include a + "Location" HTTP header that contains the URI + + of the newly-created "Individual VNF LCM operation occurrence" resource + corresponding to the instantiation operation. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: > + Used in redirection, or when a new resource has been created. This + header field shall be present if the + + response status code is 201 or 3xx. In the present document this + header field is also used if the response + + status code is 202 and a new resource was created. + style: simple + explode: false + schema: + type: string + format: url + content: {} + VnfInstanceChangeVnfPkg.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: + The operation cannot be executed + currently, due to a conflict with the state of + the resource. + Typically, this is due to the fact that another + lifecycle management operation is ongoing. + The response body shall contain a + ProblemDetails structure, in which the + "detail" attribute shall convey more + information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + VnfLcmOpOccs.Get.200: + description: > + 200 OK + + Status information for zero or more VNF lifecycle management operation + occurrences has been queried + + successfully. The response body shall contain in an array the status + information about zero or more VNF + + lifecycle operation occurrences, as defined in clause 5.5.2.13. If the + VNFM supports alternative 2 (paging) + + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource, + inclusion of the Link HTTP header in + + this response shall follow the provisions in clause 5.4.2.3 of ETSI GS + NFV-SOL 013. + headers: + Version: + description: | + The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: "This type represents a VNF lifecycle management operation occurrence. Shall be set to the value of the \"id\" attribute in the \"Grant\" representing the associated \"Individual Grant\", if such grant exists. * NOTE 1:\tThis allows the API consumer to obtain the information contained in the latest \"result\"\n notification if it has not received it due to an error or a wrongly configured subscription filter.\n* NOTE 2:\tNot more than one of changedInfo and modificationsTriggeredByVnfPkgChange shall be present. * NOTE 3:\tFor a particular affected VL, there shall be as many \"AffectedVirtualLink\" entries as needed\n for signalling the different types of changes, i.e. one per virtual link and change type.\n For instance, in the case of signaling affected VL instances involving the addition of a\n particular VL instance with links ports, one \"AffectedVirtualLink\" entry signals the addition\n of the VL by using the \"changeType\" attribute of \"AffectedVirtualLink\" structure equal to \"ADDED\",\n and another \"AffectedVirtualLink\" entry signals the addition of VNF link ports of the VL by using the\n \"changeType\" equal to \"LINK_PORT_ADDED\".\n* NOTE 4:\tA coordination action has timed out if the VNFM has not been able to read the\n \"Individual coordination action\" resource within a timeout interval after requesting the coordination\n to be started or to be cancelled. The length of the timeout interval is defined by means outside\n the scope of the present document.\n* NOTE 5: The list of rejected coordinations may be garbage collected if the LCM operation occurrence has\n reached a terminal state, i.e. one of \"COMPLETED\", \"FAILED\" and \"ROLLED_BACK\".\n" + type: object + oneOf: + - required: + - changedInfo + - required: + - modificationsTriggeredByVnfPkgChange + required: + - id + - operationState + - stateEnteredTime + - startTime + - vnfInstanceId + - operation + - isAutomaticInvocation + - isCancelPending + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + operationState: + description: > + STARTING: The LCM operation is starting. PROCESSING: The LCM + operation is currently in execution. COMPLETED: The LCM + operation has been completed successfully. FAILED_TEMP: The + LCM operation has failed and execution has stopped, but the + execution of the operation is not considered to be closed. + FAILED: The LCM operation has failed and it cannot be + retried or rolled back, as it is determined that such action + won't succeed. ROLLING_BACK: The LCM operation is currently + being rolled back. ROLLED_BACK: The LCM operation has been + successfully rolled back, i.e. The state of the VNF prior to + the original operation invocation has been restored as + closely as possible. + type: string + enum: + - STARTING + - PROCESSING + - COMPLETED + - FAILED_TEMP + - FAILED + - ROLLING_BACK + - ROLLED_BACK + stateEnteredTime: + description: > + Date-time stamp. Representation: String formatted according + to IETF RFC 3339. + type: string + format: date-time + startTime: + description: > + Date-time stamp. Representation: String formatted according + to IETF RFC 3339. + type: string + format: date-time + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + grantId: + description: | + An identifier with the intention of being globally unique. + type: string + operation: + description: > + The enumeration LcmOpType defines the permitted values to + represent VNF lifecycle operation types in VNF lifecycle + management operation occurrence resources and VNF lifecycle + management operation occurrence notifications. + + Value | Description ------|------------ INSTANTIATE | + Represents the "Instantiate VNF" LCM operation. SCALE | + Represents the "Scale VNF" LCM operation. SCALE_TO_LEVEL | + Represents the "Scale VNF to Level" LCM operation. + CHANGE_FLAVOUR | Represents the "Change VNF Flavour" LCM + operation. TERMINATE | Represents the "Terminate VNF" LCM + operation. HEAL | Represents the "Heal VNF" LCM operation. + OPERATE | Represents the "Operate VNF" LCM operation. + CHANGE_EXT_CONN | Represents the "Change external VNF + connectivity" LCM operation. MODIFY_INFO | Represents the + "Modify VNF Information" LCM operation. CREATE_SNAPSHOT | + Represents the "Create VNF Snapshot" LCM operation. + REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot" + LCM operation. CHANGE_VNFPKG | Represents the "Change + current VNF package" LCM operation. SELECT_DEPL_MODS | + Represents the "Select VNF deployable modules" LCM + operation + type: string + enum: + - INSTANTIATE + - SCALE + - SCALE_TO_LEVEL + - CHANGE_FLAVOUR + - TERMINATE + - HEAL + - OPERATE + - CHANGE_EXT_CONN + - MODIFY_INFO + - CREATE_SNAPSHOT + - REVERT_TO_SNAPSHOT + - CHANGE_VNFPKG + - SELECT_DEPL_MODS + isAutomaticInvocation: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + operationParams: + description: > + Input parameters of the LCM operation. This attribute shall + be formatted according to the request data type of the + related LCM operation. In addition, the provisions in clause + 5.7 shall apply. The following mapping between operationType + and the data type of this attribute shall apply: * + INSTANTIATE: InstantiateVnfRequest * SCALE: ScaleVnfRequest + * SCALE_TO_LEVEL: ScaleVnfToLevelRequest * CHANGE_FLAVOUR: + ChangeVnfFlavourRequest * OPERATE: OperateVnfRequest * HEAL: + HealVnfRequest * CHANGE_EXT_CONN: + ChangeExtVnfConnectivityRequest * TERMINATE: + TerminateVnfRequest * MODIFY_INFO: + VnfInfoModificationRequest * CREATE_SNAPSHOT: + CreateVnfSnapshotRequest * REVERT_TO_SNAPSHOT: + RevertToVnfSnapshotRequest * CHANGE_VNFPKG: + ChangeCurrentVnfPkgRequest * SELECT_DEPL_MODS: + SelectVnfDeployableModulesRequest + type: object + isCancelPending: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + cancelMode: + description: > + Cancellation mode. GRACEFUL: If the VNF LCM operation + occurrence is in "PROCESSING" or "ROLLING_BACK" state, the + VNFM shall not start any new resource management operation + and shall wait for the ongoing resource management + operations in the underlying system, typically the VIM, to + finish execution or to time out. After that, the VNFM shall + put the operation occurrence into the FAILED_TEMP state. If + the VNF LCM operation occurrence is in "STARTING" state, the + VNFM shall not start any resource management operation and + shall wait for the granting request to finish execution or + time out. After that, the VNFM shall put the operation + occurrence into the ROLLED_BACK state. FORCEFUL: If the VNF + LCM operation occurrence is in "PROCESSING" or + "ROLLING_BACK" state, the VNFM shall not start any new + resource management operation, shall cancel the ongoing + resource management operations in the underlying system, + typically the VIM, and shall wait for the cancellation to + finish or to time out. After that, the VNFM shall put the + operation occurrence into the FAILED_TEMP state. If the VNF + LCM operation occurrence is in "STARTING" state, the VNFM + shall not start any resource management operation and put + the operation occurrence into the ROLLED_BACK state. + type: string + enum: + - GRACEFUL + - FORCEFUL + error: + description: > + The definition of the general "ProblemDetails" data + structure from IETF RFC 7807 is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807, + 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + resourceChanges: + description: > + This attribute contains information about the cumulative + changes to virtualised resources that were performed so far + by the LCM operation since its start, if applicable. + type: object + properties: + affectedVnfcs: + description: > + Information about VNFC instances that were affected + during the lifecycle operation. See note 1. + type: array + items: + description: > + This type provides information about added, deleted, + modified and temporary VNFCs. + type: object + required: + - id + - vduId + - changeType + - computeResource + properties: + id: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: > + Signals the type of change. Permitted values: * + ADDED * REMOVED * MODIFIED * TEMPORARY For a + temporary resource, an AffectedVnfc structure + exists as long as the temporary resource exists. + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + metadata: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + affectedVnfcCpIds: + description: > + Identifiers of CP(s) of the VNFC instance that + were affected by the change. Shall be present for + those affected CPs of the VNFC instance that are + associated to an external CP of the VNF instance. + May be present for further affected CPs of the + VNFC instance. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + addedStorageResourceIds: + description: > + References to VirtualStorage resources that have + been added. Each value refers to a + VirtualStorageResourceInfo item in the VnfInstance + that was added to the VNFC. It shall be provided + if at least one storage resource was added to the + VNFC. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + removedStorageResourceIds: + description: > + References to VirtualStorage resources that have + been removed. The value contains the identifier of + a VirtualStorageResourceInfo item that has been + removed from the VNFC, and might no longer exist + in the VnfInstance. It shall be provided if at + least one storage resource was removed from the + VNFC. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + affectedVirtualLinks: + description: > + Information about VL instances that were affected during + the lifecycle operation. See note 1 and note 3. + type: array + items: + description: "This type provides information about added, deleted, modified and temporary VLs, and added or removed VNF link ports.\nNOTE:\tWhen signalling the addition (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) of VNF link ports, \n the \"networkResource\" attribute refers to the affected virtual link instance, not the link port \n instance. The resource handles of the affected VNF link ports can be found by dereferencing the \n identifiers in the \"vnfLinkPortIds\" attribute.\n" + type: object + required: + - id + - vnfVirtualLinkDescId + - changeType + - networkResource + properties: + id: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: > + Signals the type of change. Permitted values: * + ADDED * REMOVED * MODIFIED * TEMPORARY * + LINK_PORT_ADDED * LINK_PORT_REMOVED For a + temporary resource, an AffectedVirtualLink + structure exists as long as the temporary resource + exists. When signalling the addition + (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) + of VNF link ports, the "networkResource" attribute + refers to the affected virtual link instance, not + the link port instance. The resource handles of + the affected VNF link ports can be found by + dereferencing the identifiers in the + "vnfLinkPortIds" attribute. + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + - LINK_PORT_ADDED + - LINK_PORT_REMOVED + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + vnfLinkPortIds: + description: > + Identifiers of the link ports of the affected VL + related to the change. Each identifier references + a "VnfLinkPortInfo" structure. + + Shall be set when changeType is equal to + "LINK_PORT_ADDED" or "LINK_PORT_REMOVED", and the + related "VnfLinkPortInfo" structures are present + (case "added") or have been present (case + "removed") in the "VnfVirtualLinkResourceInfo" or + "ExtManagedVirtualLinkInfo" structures that are + represented by the "vnfVirtualLinkResourceInfo" + or "extManagedVirtualLinkInfo" attribute in the + "VnfInstance" structure. See note. + type: array + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + metadata: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + affectedExtLinkPorts: + description: > + Information about external VNF link ports that were + affected during the lifecycle operation. See note 1. + type: array + items: + description: > + This type provides information about added and deleted + external link ports (link ports attached to external + virtual links). + type: object + required: + - id + - changeType + - extCpInstanceId + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: "Signals the type of change. Permitted values: -\tADDED - MODIFIED -\tREMOVED\n" + type: string + enum: + - ADDED + - MODIFIED + - REMOVED + extCpInstanceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + affectedVirtualStorages: + description: > + Information about virtualised storage instances that + were affected during the lifecycle operation. See note + 1. + type: array + items: + description: > + This type provides information about added, deleted, + modified and temporary virtual storage resources. + type: object + required: + - id + - virtualStorageDescId + - changeType + - storageResource + properties: + id: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: > + Signals the type of change. Permitted values: * + ADDED * REMOVED * MODIFIED * TEMPORARY For a + temporary resource, an AffectedVirtualStorage + structure exists as long as the temporary resource + exists. + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + metadata: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + changedInfo: + description: "This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource. The attributes that can be included consist of those requested to be modified explicitly in the \"VnfInfoModificationRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly e.g. when modifying the referenced VNF package. * NOTE:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute)\n was modified implicitly following a request to modify the \"vnfdId\" attribute, by\n copying the value of this attribute from the VNFD in the VNF Package identified\n by the \"vnfdId\" attribute.\n" + type: object + properties: + vnfInstanceName: + description: > + If present, this attribute signals modifications of the + "vnfInstanceName" attribute in "VnfInstance" as defined + in clause 5.5.2.12.. + type: string + vnfInstanceDescription: + description: > + If present, this attribute signals modifications of the + "vnfInstanceDescription" attribute in "VnfInstance", as + defined in clause 5.5.2.12.. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProvider: + description: > + If present, this attribute signals modifications of the + "vnfProvider" attribute in "VnfInstance". See note. + type: string + vnfProductName: + description: > + If present, this attribute signals modifications of the + "vnfProductName" attribute in "VnfInstance". See note. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vnfcInfoModifications: + description: > + If present, this attribute signals modifications of + certain entries in the "vnfcInfo" attribute array in the + "instantiatedVnfInfo" attribute of "VnfInstance", as + defined in clause 5.5.2.12. + type: array + items: + description: "This type represents modifications of an entry in an array of \"VnfcInfo\" objects. * NOTE:\tThe attribute \"id\" in this data type represents the same identifier as the attribute\n \"vnfcInstanceId\" in other related data types in the present document. For reasons of backward\n compatibility, this misalignment is not corrected.\n" + type: object + required: + - id + - vnfcConfigurableProperties + properties: + id: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfcConfigurableProperties: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + affectedVipCps: + description: > + Information about virtual IP CP instances that were affected + during the execution of the lifecycle management operation. + type: array + items: + description: > + This type provides information about added, deleted and + modified virtual IP CP instances. + type: object + required: + - cpInstanceId + - cpdId + - changeType + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: "Signals the type of change. Permitted values: -\tADDED -\tREMOVED -\tMODIFIED\n" + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + changedExtConnectivity: + description: > + Information about changed external connectivity, if + applicable. See note 1. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service is + a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the CISM + and shall be absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used + by a VNF instance. Information about the + resource is available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id + is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See + note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the + VIM or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall + be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the current CP + configuration information for the connection of + external CPs to the external virtual link. See note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured + on the CP instances created from the respective + CPD. The key of the map which identifies the + individual VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. + The entries shall be applied by the VNFM + according to the rules of JSON Merge Patch (see + IETF RFC 7396). See notes 2, 3, 4, 5 and 6. In + case of deleting an external CP, the list of + instances to be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided + link port, or a network attachment definition + resource of secondary container cluster + network, or network address information per + instance of an external connection point. In + the case of VM-based deployment of the VNFC + exposing the external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of + the VNFC exposing the external CP, the VNFM + shall use the network attachment definition + resource of secondary container cluster + network when connecting the CP to the external + VL. + + * NOTE 1: The following conditions apply to + the attributes "linkPortId" and + "cpProtocolData" for an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to + the attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. + If set to True, the VNFM shall create a + link port. If set to False, the VNFM shall + not create a link port. This attribute is + only applicable for external CP instances + without a floating IP address that expose + a VIP CP instance for which a dedicated IP + address is allocated. It shall be present + in that case and shall be absent + otherwise. + type: boolean + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects + the CP to a VL and the domain names for + the external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the + CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored. + + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD + is activated/deactivated and for an + activated security group rule the values + of attributes defined in the VNFD that can + be overriden such as "portRangeMin" and + "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification + of the interface to attach the external CP + to a secondary container cluster network. + It is only applicable if the external CP + is connected or to be connected to a + secondary container cluster network. It + shall not be present if the external CP is + related to a virtual network not + categorized as secondary container cluster + network. See notes 2, 3 and 4. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + extNetAttDefResource: + description: > + Network attachment definition resources that provide + the specification of the interface to attach + connection points to this VL. + type: array + items: + description: > + This type contains information related to a network + attachment definition resource that provides the + specification of the interface used to connect one + or multiple connection points to a secondary + container cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of being + globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used + by a VNF instance. Information about the + resource is available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id + is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See + note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the + VIM or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall + be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated to this + network attachment definition resource. Shall be + present when the network attachment definition + resource is used for external connectivity by + the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to this + network attachment definition resource. May be + present when the network attachment definition + resource is used for internal connectivity by + the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + routingResource: + description: > + Network resources that provide the forwarding/routing + capabilities associated to the network resource + realizing this VL. + type: array + items: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + modificationsTriggeredByVnfPkgChange: + description: "This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource when changing the current VNF package. The attributes that can be included consist of those requested to be modified explicitly in the \"ChangeCurrentVnfPkgRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly during the operation.\nNOTE 1:\tThis attribute represents the delta (semantics as per IETF RFC 7396, JSON Merge Patch) between the value \n of the attribute at the start of the \"Change current VNF package\" operation and the value of the attribute \n at its completion.\nNOTE 2:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) was modified implicitly \n during the related operation and contains a copy of the value of the related attribute from the VNFD in the \n VNF Package identified by the \"vnfdId\" attribute.\n" + type: object + properties: + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProvider: + description: > + If present, this attribute signals the new value of the + "vnfProvider" attribute in "VnfInstance". See note 2. + type: string + vnfProductName: + description: > + If present, this attribute signals the new value of the + "vnfProductName" attribute in "VnfInstance". See note 2. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vnfSnapshotInfoId: + description: | + An identifier with the intention of being globally unique. + type: string + lcmCoordinations: + description: > + Information about LCM coordination actions (see clause 10) + related to this LCM operation occurrence. + type: object + required: + - id + - coordinationActionName + - startTime + - endpointType + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + coordinationActionName: + description: > + An identifier with the intention of being globally + unique. + type: string + coordinationResult: + description: > + The enumeration LcmCoordResultType defines the permitted + values to represent the result of executing an LCM + coordination action. The coordination result also + implies the action to be performed by the VNFM as the + follow-up to this coordination. Value | Description + ------|------------ CONTINUE | The related LCM operation + shall be continued, staying in the state "PROCESSING". + ABORT | The related LCM operation shall be aborted by + transitioning into the state "FAILED_TEMP". CANCELLED | + The coordination action has been cancelled upon request + of the API consumer, i.e. the VNFM. The related LCM + operation shall be aborted by transitioning into the + state "FAILED_TEMP". + type: string + enum: + - CONTINUE + - ABORT + - CANCELLED + startTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + endTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + endpointType: + description: > + The endpoint type used by this coordination action. + Valid values: - MGMT: coordination with other operation + supporting management systems (e.g. EM) - VNF: + coordination with the VNF instance + type: string + enum: + - MGMT + - VNF + delay: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + rejectedLcmCoordinations: + description: > + Information about LCM coordination actions (see clause 10) + that were rejected by 503 error which means they will be + tried again after a delay. See note 5. + type: object + required: + - coordinationActionName + - rejectionTime + - endpointType + - delay + properties: + coordinationActionName: + description: > + An identifier with the intention of being globally + unique. + type: string + rejectionTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + endpointType: + description: > + The endpoint type used by this coordination action. + Valid values: - MGMT: coordination with other operation + supporting management systems (e.g. EM) - VNF: + coordination with the VNF instance + type: string + enum: + - MGMT + - VNF + delay: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + warnings: + description: > + Warning messages that were generated while the operation was + executing. + + If the operation has included LCM coordination actions and + these have resulted in warnings, such warnings should be + added to this attribute. + type: array + items: + type: string + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + - vnfInstance + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + grant: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + cancel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + retry: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + rollback: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + fail: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualVnfLcmOpOcc.Get.200: + description: > + 200 OK + + Information about an individual VNF instance has been queried + successfully. The response body shall contain + + status information about a VNF lifecycle management operation + occurrence. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: "This type represents a VNF lifecycle management operation occurrence. Shall be set to the value of the \"id\" attribute in the \"Grant\" representing the associated \"Individual Grant\", if such grant exists. * NOTE 1:\tThis allows the API consumer to obtain the information contained in the latest \"result\"\n notification if it has not received it due to an error or a wrongly configured subscription filter.\n* NOTE 2:\tNot more than one of changedInfo and modificationsTriggeredByVnfPkgChange shall be present. * NOTE 3:\tFor a particular affected VL, there shall be as many \"AffectedVirtualLink\" entries as needed\n for signalling the different types of changes, i.e. one per virtual link and change type.\n For instance, in the case of signaling affected VL instances involving the addition of a\n particular VL instance with links ports, one \"AffectedVirtualLink\" entry signals the addition\n of the VL by using the \"changeType\" attribute of \"AffectedVirtualLink\" structure equal to \"ADDED\",\n and another \"AffectedVirtualLink\" entry signals the addition of VNF link ports of the VL by using the\n \"changeType\" equal to \"LINK_PORT_ADDED\".\n* NOTE 4:\tA coordination action has timed out if the VNFM has not been able to read the\n \"Individual coordination action\" resource within a timeout interval after requesting the coordination\n to be started or to be cancelled. The length of the timeout interval is defined by means outside\n the scope of the present document.\n* NOTE 5: The list of rejected coordinations may be garbage collected if the LCM operation occurrence has\n reached a terminal state, i.e. one of \"COMPLETED\", \"FAILED\" and \"ROLLED_BACK\".\n" + type: object + oneOf: + - required: + - changedInfo + - required: + - modificationsTriggeredByVnfPkgChange + required: + - id + - operationState + - stateEnteredTime + - startTime + - vnfInstanceId + - operation + - isAutomaticInvocation + - isCancelPending + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + operationState: + description: > + STARTING: The LCM operation is starting. PROCESSING: The LCM + operation is currently in execution. COMPLETED: The LCM + operation has been completed successfully. FAILED_TEMP: The + LCM operation has failed and execution has stopped, but the + execution of the operation is not considered to be closed. + FAILED: The LCM operation has failed and it cannot be retried + or rolled back, as it is determined that such action won't + succeed. ROLLING_BACK: The LCM operation is currently being + rolled back. ROLLED_BACK: The LCM operation has been + successfully rolled back, i.e. The state of the VNF prior to + the original operation invocation has been restored as closely + as possible. + type: string + enum: + - STARTING + - PROCESSING + - COMPLETED + - FAILED_TEMP + - FAILED + - ROLLING_BACK + - ROLLED_BACK + stateEnteredTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + startTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + grantId: + description: | + An identifier with the intention of being globally unique. + type: string + operation: + description: > + The enumeration LcmOpType defines the permitted values to + represent VNF lifecycle operation types in VNF lifecycle + management operation occurrence resources and VNF lifecycle + management operation occurrence notifications. + + Value | Description ------|------------ INSTANTIATE | + Represents the "Instantiate VNF" LCM operation. SCALE | + Represents the "Scale VNF" LCM operation. SCALE_TO_LEVEL | + Represents the "Scale VNF to Level" LCM operation. + CHANGE_FLAVOUR | Represents the "Change VNF Flavour" LCM + operation. TERMINATE | Represents the "Terminate VNF" LCM + operation. HEAL | Represents the "Heal VNF" LCM operation. + OPERATE | Represents the "Operate VNF" LCM operation. + CHANGE_EXT_CONN | Represents the "Change external VNF + connectivity" LCM operation. MODIFY_INFO | Represents the + "Modify VNF Information" LCM operation. CREATE_SNAPSHOT | + Represents the "Create VNF Snapshot" LCM operation. + REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot" + LCM operation. CHANGE_VNFPKG | Represents the "Change current + VNF package" LCM operation. SELECT_DEPL_MODS | Represents the + "Select VNF deployable modules" LCM operation + type: string + enum: + - INSTANTIATE + - SCALE + - SCALE_TO_LEVEL + - CHANGE_FLAVOUR + - TERMINATE + - HEAL + - OPERATE + - CHANGE_EXT_CONN + - MODIFY_INFO + - CREATE_SNAPSHOT + - REVERT_TO_SNAPSHOT + - CHANGE_VNFPKG + - SELECT_DEPL_MODS + isAutomaticInvocation: + description: | + The Boolean is a data type having two values (true and false). + type: boolean + operationParams: + description: > + Input parameters of the LCM operation. This attribute shall be + formatted according to the request data type of the related + LCM operation. In addition, the provisions in clause 5.7 shall + apply. The following mapping between operationType and the + data type of this attribute shall apply: * INSTANTIATE: + InstantiateVnfRequest * SCALE: ScaleVnfRequest * + SCALE_TO_LEVEL: ScaleVnfToLevelRequest * CHANGE_FLAVOUR: + ChangeVnfFlavourRequest * OPERATE: OperateVnfRequest * HEAL: + HealVnfRequest * CHANGE_EXT_CONN: + ChangeExtVnfConnectivityRequest * TERMINATE: + TerminateVnfRequest * MODIFY_INFO: VnfInfoModificationRequest + * CREATE_SNAPSHOT: CreateVnfSnapshotRequest * + REVERT_TO_SNAPSHOT: RevertToVnfSnapshotRequest * + CHANGE_VNFPKG: ChangeCurrentVnfPkgRequest * SELECT_DEPL_MODS: + SelectVnfDeployableModulesRequest + type: object + isCancelPending: + description: | + The Boolean is a data type having two values (true and false). + type: boolean + cancelMode: + description: > + Cancellation mode. GRACEFUL: If the VNF LCM operation + occurrence is in "PROCESSING" or "ROLLING_BACK" state, the + VNFM shall not start any new resource management operation and + shall wait for the ongoing resource management operations in + the underlying system, typically the VIM, to finish execution + or to time out. After that, the VNFM shall put the operation + occurrence into the FAILED_TEMP state. If the VNF LCM + operation occurrence is in "STARTING" state, the VNFM shall + not start any resource management operation and shall wait for + the granting request to finish execution or time out. After + that, the VNFM shall put the operation occurrence into the + ROLLED_BACK state. FORCEFUL: If the VNF LCM operation + occurrence is in "PROCESSING" or "ROLLING_BACK" state, the + VNFM shall not start any new resource management operation, + shall cancel the ongoing resource management operations in the + underlying system, typically the VIM, and shall wait for the + cancellation to finish or to time out. After that, the VNFM + shall put the operation occurrence into the FAILED_TEMP state. + If the VNF LCM operation occurrence is in "STARTING" state, + the VNFM shall not start any resource management operation and + put the operation occurrence into the ROLLED_BACK state. + type: string + enum: + - GRACEFUL + - FORCEFUL + error: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + resourceChanges: + description: > + This attribute contains information about the cumulative + changes to virtualised resources that were performed so far by + the LCM operation since its start, if applicable. + type: object + properties: + affectedVnfcs: + description: > + Information about VNFC instances that were affected during + the lifecycle operation. See note 1. + type: array + items: + description: > + This type provides information about added, deleted, + modified and temporary VNFCs. + type: object + required: + - id + - vduId + - changeType + - computeResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: > + Signals the type of change. Permitted values: * + ADDED * REMOVED * MODIFIED * TEMPORARY For a + temporary resource, an AffectedVnfc structure exists + as long as the temporary resource exists. + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + affectedVnfcCpIds: + description: > + Identifiers of CP(s) of the VNFC instance that were + affected by the change. Shall be present for those + affected CPs of the VNFC instance that are + associated to an external CP of the VNF instance. + May be present for further affected CPs of the VNFC + instance. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + addedStorageResourceIds: + description: > + References to VirtualStorage resources that have + been added. Each value refers to a + VirtualStorageResourceInfo item in the VnfInstance + that was added to the VNFC. It shall be provided if + at least one storage resource was added to the VNFC. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + removedStorageResourceIds: + description: > + References to VirtualStorage resources that have + been removed. The value contains the identifier of a + VirtualStorageResourceInfo item that has been + removed from the VNFC, and might no longer exist in + the VnfInstance. It shall be provided if at least + one storage resource was removed from the VNFC. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + affectedVirtualLinks: + description: > + Information about VL instances that were affected during + the lifecycle operation. See note 1 and note 3. + type: array + items: + description: "This type provides information about added, deleted, modified and temporary VLs, and added or removed VNF link ports.\nNOTE:\tWhen signalling the addition (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) of VNF link ports, \n the \"networkResource\" attribute refers to the affected virtual link instance, not the link port \n instance. The resource handles of the affected VNF link ports can be found by dereferencing the \n identifiers in the \"vnfLinkPortIds\" attribute.\n" + type: object + required: + - id + - vnfVirtualLinkDescId + - changeType + - networkResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: > + Signals the type of change. Permitted values: * + ADDED * REMOVED * MODIFIED * TEMPORARY * + LINK_PORT_ADDED * LINK_PORT_REMOVED For a temporary + resource, an AffectedVirtualLink structure exists as + long as the temporary resource exists. When + signalling the addition (LINK_PORT_ADDED) or removal + (LINK_PORT_REMOVED) of VNF link ports, the + "networkResource" attribute refers to the affected + virtual link instance, not the link port instance. + The resource handles of the affected VNF link ports + can be found by dereferencing the identifiers in the + "vnfLinkPortIds" attribute. + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + - LINK_PORT_ADDED + - LINK_PORT_REMOVED + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + vnfLinkPortIds: + description: > + Identifiers of the link ports of the affected VL + related to the change. Each identifier references a + "VnfLinkPortInfo" structure. + + Shall be set when changeType is equal to + "LINK_PORT_ADDED" or "LINK_PORT_REMOVED", and the + related "VnfLinkPortInfo" structures are present + (case "added") or have been present (case "removed") + in the "VnfVirtualLinkResourceInfo" or + "ExtManagedVirtualLinkInfo" structures that are + represented by the "vnfVirtualLinkResourceInfo" or + "extManagedVirtualLinkInfo" attribute in the + "VnfInstance" structure. See note. + type: array + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + affectedExtLinkPorts: + description: > + Information about external VNF link ports that were + affected during the lifecycle operation. See note 1. + type: array + items: + description: > + This type provides information about added and deleted + external link ports (link ports attached to external + virtual links). + type: object + required: + - id + - changeType + - extCpInstanceId + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: "Signals the type of change. Permitted values: -\tADDED - MODIFIED -\tREMOVED\n" + type: string + enum: + - ADDED + - MODIFIED + - REMOVED + extCpInstanceId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + affectedVirtualStorages: + description: > + Information about virtualised storage instances that were + affected during the lifecycle operation. See note 1. + type: array + items: + description: > + This type provides information about added, deleted, + modified and temporary virtual storage resources. + type: object + required: + - id + - virtualStorageDescId + - changeType + - storageResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: > + Signals the type of change. Permitted values: * + ADDED * REMOVED * MODIFIED * TEMPORARY For a + temporary resource, an AffectedVirtualStorage + structure exists as long as the temporary resource + exists. + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + changedInfo: + description: "This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource. The attributes that can be included consist of those requested to be modified explicitly in the \"VnfInfoModificationRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly e.g. when modifying the referenced VNF package. * NOTE:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute)\n was modified implicitly following a request to modify the \"vnfdId\" attribute, by\n copying the value of this attribute from the VNFD in the VNF Package identified\n by the \"vnfdId\" attribute.\n" + type: object + properties: + vnfInstanceName: + description: > + If present, this attribute signals modifications of the + "vnfInstanceName" attribute in "VnfInstance" as defined in + clause 5.5.2.12.. + type: string + vnfInstanceDescription: + description: > + If present, this attribute signals modifications of the + "vnfInstanceDescription" attribute in "VnfInstance", as + defined in clause 5.5.2.12.. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfProvider: + description: > + If present, this attribute signals modifications of the + "vnfProvider" attribute in "VnfInstance". See note. + type: string + vnfProductName: + description: > + If present, this attribute signals modifications of the + "vnfProductName" attribute in "VnfInstance". See note. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vnfcInfoModifications: + description: > + If present, this attribute signals modifications of + certain entries in the "vnfcInfo" attribute array in the + "instantiatedVnfInfo" attribute of "VnfInstance", as + defined in clause 5.5.2.12. + type: array + items: + description: "This type represents modifications of an entry in an array of \"VnfcInfo\" objects. * NOTE:\tThe attribute \"id\" in this data type represents the same identifier as the attribute\n \"vnfcInstanceId\" in other related data types in the present document. For reasons of backward\n compatibility, this misalignment is not corrected.\n" + type: object + required: + - id + - vnfcConfigurableProperties + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfcConfigurableProperties: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + affectedVipCps: + description: > + Information about virtual IP CP instances that were affected + during the execution of the lifecycle management operation. + type: array + items: + description: > + This type provides information about added, deleted and + modified virtual IP CP instances. + type: object + required: + - cpInstanceId + - cpdId + - changeType + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: "Signals the type of change. Permitted values: -\tADDED -\tREMOVED -\tMODIFIED\n" + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + changedExtConnectivity: + description: > + Information about changed external connectivity, if + applicable. See note 1. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is known + to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service is a + Kubernetes® instance the resourceId shall be populated + in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the current CP + configuration information for the connection of external + CPs to the external virtual link. See note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. The + entries shall be applied by the VNFM according to + the rules of JSON Merge Patch (see IETF RFC 7396). + See notes 2, 3, 4, 5 and 6. In case of deleting an + external CP, the list of instances to be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the + CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored. + + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + extNetAttDefResource: + description: > + Network attachment definition resources that provide the + specification of the interface to attach connection + points to this VL. + type: array + items: + description: > + This type contains information related to a network + attachment definition resource that provides the + specification of the interface used to connect one or + multiple connection points to a secondary container + cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of being globally + unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated to this + network attachment definition resource. Shall be + present when the network attachment definition + resource is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to this + network attachment definition resource. May be + present when the network attachment definition + resource is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + routingResource: + description: > + Network resources that provide the forwarding/routing + capabilities associated to the network resource + realizing this VL. + type: array + items: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service is + a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the CISM + and shall be absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + modificationsTriggeredByVnfPkgChange: + description: "This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource when changing the current VNF package. The attributes that can be included consist of those requested to be modified explicitly in the \"ChangeCurrentVnfPkgRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly during the operation.\nNOTE 1:\tThis attribute represents the delta (semantics as per IETF RFC 7396, JSON Merge Patch) between the value \n of the attribute at the start of the \"Change current VNF package\" operation and the value of the attribute \n at its completion.\nNOTE 2:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) was modified implicitly \n during the related operation and contains a copy of the value of the related attribute from the VNFD in the \n VNF Package identified by the \"vnfdId\" attribute.\n" + type: object + properties: + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfProvider: + description: > + If present, this attribute signals the new value of the + "vnfProvider" attribute in "VnfInstance". See note 2. + type: string + vnfProductName: + description: > + If present, this attribute signals the new value of the + "vnfProductName" attribute in "VnfInstance". See note 2. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vnfSnapshotInfoId: + description: | + An identifier with the intention of being globally unique. + type: string + lcmCoordinations: + description: > + Information about LCM coordination actions (see clause 10) + related to this LCM operation occurrence. + type: object + required: + - id + - coordinationActionName + - startTime + - endpointType + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + coordinationActionName: + description: | + An identifier with the intention of being globally unique. + type: string + coordinationResult: + description: > + The enumeration LcmCoordResultType defines the permitted + values to represent the result of executing an LCM + coordination action. The coordination result also implies + the action to be performed by the VNFM as the follow-up to + this coordination. Value | Description ------|------------ + CONTINUE | The related LCM operation shall be continued, + staying in the state "PROCESSING". ABORT | The related LCM + operation shall be aborted by transitioning into the state + "FAILED_TEMP". CANCELLED | The coordination action has + been cancelled upon request of the API consumer, i.e. the + VNFM. The related LCM operation shall be aborted by + transitioning into the state "FAILED_TEMP". + type: string + enum: + - CONTINUE + - ABORT + - CANCELLED + startTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + endTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + endpointType: + description: > + The endpoint type used by this coordination action. Valid + values: - MGMT: coordination with other operation + supporting management systems (e.g. EM) - VNF: + coordination with the VNF instance + type: string + enum: + - MGMT + - VNF + delay: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + rejectedLcmCoordinations: + description: > + Information about LCM coordination actions (see clause 10) + that were rejected by 503 error which means they will be tried + again after a delay. See note 5. + type: object + required: + - coordinationActionName + - rejectionTime + - endpointType + - delay + properties: + coordinationActionName: + description: | + An identifier with the intention of being globally unique. + type: string + rejectionTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + endpointType: + description: > + The endpoint type used by this coordination action. Valid + values: - MGMT: coordination with other operation + supporting management systems (e.g. EM) - VNF: + coordination with the VNF instance + type: string + enum: + - MGMT + - VNF + delay: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + warnings: + description: > + Warning messages that were generated while the operation was + executing. + + If the operation has included LCM coordination actions and + these have resulted in warnings, such warnings should be added + to this attribute. + type: array + items: + type: string + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + - vnfInstance + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + grant: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + cancel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + retry: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + rollback: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + fail: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + VnfLcmOpOccRetry.Post.202: + description: > + 202 ACCEPTED + + The request has been accepted for processing, but processing has not + been completed. The response shall + + have an empty message content. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + content: {} + VnfLcmOpOccRetry.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the VNF LCM operation + occurrence. + Typically, this is due to the fact that the VNF LCM + operation occurrence is not in FAILED_TEMP state + or another error handling action is starting such as + rollback or fail. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + VnfLcmOpOccRollback.Post.202: + description: > + 202 ACCEPTED + + The request has been accepted for processing, but processing has not + been completed. The response shall have + + an empty message content. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + content: {} + VnfLcmOpOccRollback.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the VNF LCM operation + occurrence. + Typically, this is due to the fact that the VNF LCM + operation occurrence is not in FAILED_TEMP state + or another error handling action is starting such as + retry or fail. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + VnfLcmOpOccFail.Post.200: + description: > + 200 OK + + The state of the VNF lifecycle management operation occurrence has been + changed successfully. The response + + shall include a representation of the "Individual VNF lifecycle + operation occurrence" resource. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: "This type represents a VNF lifecycle management operation occurrence. Shall be set to the value of the \"id\" attribute in the \"Grant\" representing the associated \"Individual Grant\", if such grant exists. * NOTE 1:\tThis allows the API consumer to obtain the information contained in the latest \"result\"\n notification if it has not received it due to an error or a wrongly configured subscription filter.\n* NOTE 2:\tNot more than one of changedInfo and modificationsTriggeredByVnfPkgChange shall be present. * NOTE 3:\tFor a particular affected VL, there shall be as many \"AffectedVirtualLink\" entries as needed\n for signalling the different types of changes, i.e. one per virtual link and change type.\n For instance, in the case of signaling affected VL instances involving the addition of a\n particular VL instance with links ports, one \"AffectedVirtualLink\" entry signals the addition\n of the VL by using the \"changeType\" attribute of \"AffectedVirtualLink\" structure equal to \"ADDED\",\n and another \"AffectedVirtualLink\" entry signals the addition of VNF link ports of the VL by using the\n \"changeType\" equal to \"LINK_PORT_ADDED\".\n* NOTE 4:\tA coordination action has timed out if the VNFM has not been able to read the\n \"Individual coordination action\" resource within a timeout interval after requesting the coordination\n to be started or to be cancelled. The length of the timeout interval is defined by means outside\n the scope of the present document.\n* NOTE 5: The list of rejected coordinations may be garbage collected if the LCM operation occurrence has\n reached a terminal state, i.e. one of \"COMPLETED\", \"FAILED\" and \"ROLLED_BACK\".\n" + type: object + oneOf: + - required: + - changedInfo + - required: + - modificationsTriggeredByVnfPkgChange + required: + - id + - operationState + - stateEnteredTime + - startTime + - vnfInstanceId + - operation + - isAutomaticInvocation + - isCancelPending + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + operationState: + description: > + STARTING: The LCM operation is starting. PROCESSING: The LCM + operation is currently in execution. COMPLETED: The LCM + operation has been completed successfully. FAILED_TEMP: The + LCM operation has failed and execution has stopped, but the + execution of the operation is not considered to be closed. + FAILED: The LCM operation has failed and it cannot be retried + or rolled back, as it is determined that such action won't + succeed. ROLLING_BACK: The LCM operation is currently being + rolled back. ROLLED_BACK: The LCM operation has been + successfully rolled back, i.e. The state of the VNF prior to + the original operation invocation has been restored as closely + as possible. + type: string + enum: + - STARTING + - PROCESSING + - COMPLETED + - FAILED_TEMP + - FAILED + - ROLLING_BACK + - ROLLED_BACK + stateEnteredTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + startTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + grantId: + description: | + An identifier with the intention of being globally unique. + type: string + operation: + description: > + The enumeration LcmOpType defines the permitted values to + represent VNF lifecycle operation types in VNF lifecycle + management operation occurrence resources and VNF lifecycle + management operation occurrence notifications. + + Value | Description ------|------------ INSTANTIATE | + Represents the "Instantiate VNF" LCM operation. SCALE | + Represents the "Scale VNF" LCM operation. SCALE_TO_LEVEL | + Represents the "Scale VNF to Level" LCM operation. + CHANGE_FLAVOUR | Represents the "Change VNF Flavour" LCM + operation. TERMINATE | Represents the "Terminate VNF" LCM + operation. HEAL | Represents the "Heal VNF" LCM operation. + OPERATE | Represents the "Operate VNF" LCM operation. + CHANGE_EXT_CONN | Represents the "Change external VNF + connectivity" LCM operation. MODIFY_INFO | Represents the + "Modify VNF Information" LCM operation. CREATE_SNAPSHOT | + Represents the "Create VNF Snapshot" LCM operation. + REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot" + LCM operation. CHANGE_VNFPKG | Represents the "Change current + VNF package" LCM operation. SELECT_DEPL_MODS | Represents the + "Select VNF deployable modules" LCM operation + type: string + enum: + - INSTANTIATE + - SCALE + - SCALE_TO_LEVEL + - CHANGE_FLAVOUR + - TERMINATE + - HEAL + - OPERATE + - CHANGE_EXT_CONN + - MODIFY_INFO + - CREATE_SNAPSHOT + - REVERT_TO_SNAPSHOT + - CHANGE_VNFPKG + - SELECT_DEPL_MODS + isAutomaticInvocation: + description: | + The Boolean is a data type having two values (true and false). + type: boolean + operationParams: + description: > + Input parameters of the LCM operation. This attribute shall be + formatted according to the request data type of the related + LCM operation. In addition, the provisions in clause 5.7 shall + apply. The following mapping between operationType and the + data type of this attribute shall apply: * INSTANTIATE: + InstantiateVnfRequest * SCALE: ScaleVnfRequest * + SCALE_TO_LEVEL: ScaleVnfToLevelRequest * CHANGE_FLAVOUR: + ChangeVnfFlavourRequest * OPERATE: OperateVnfRequest * HEAL: + HealVnfRequest * CHANGE_EXT_CONN: + ChangeExtVnfConnectivityRequest * TERMINATE: + TerminateVnfRequest * MODIFY_INFO: VnfInfoModificationRequest + * CREATE_SNAPSHOT: CreateVnfSnapshotRequest * + REVERT_TO_SNAPSHOT: RevertToVnfSnapshotRequest * + CHANGE_VNFPKG: ChangeCurrentVnfPkgRequest * SELECT_DEPL_MODS: + SelectVnfDeployableModulesRequest + type: object + isCancelPending: + description: | + The Boolean is a data type having two values (true and false). + type: boolean + cancelMode: + description: > + Cancellation mode. GRACEFUL: If the VNF LCM operation + occurrence is in "PROCESSING" or "ROLLING_BACK" state, the + VNFM shall not start any new resource management operation and + shall wait for the ongoing resource management operations in + the underlying system, typically the VIM, to finish execution + or to time out. After that, the VNFM shall put the operation + occurrence into the FAILED_TEMP state. If the VNF LCM + operation occurrence is in "STARTING" state, the VNFM shall + not start any resource management operation and shall wait for + the granting request to finish execution or time out. After + that, the VNFM shall put the operation occurrence into the + ROLLED_BACK state. FORCEFUL: If the VNF LCM operation + occurrence is in "PROCESSING" or "ROLLING_BACK" state, the + VNFM shall not start any new resource management operation, + shall cancel the ongoing resource management operations in the + underlying system, typically the VIM, and shall wait for the + cancellation to finish or to time out. After that, the VNFM + shall put the operation occurrence into the FAILED_TEMP state. + If the VNF LCM operation occurrence is in "STARTING" state, + the VNFM shall not start any resource management operation and + put the operation occurrence into the ROLLED_BACK state. + type: string + enum: + - GRACEFUL + - FORCEFUL + error: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + resourceChanges: + description: > + This attribute contains information about the cumulative + changes to virtualised resources that were performed so far by + the LCM operation since its start, if applicable. + type: object + properties: + affectedVnfcs: + description: > + Information about VNFC instances that were affected during + the lifecycle operation. See note 1. + type: array + items: + description: > + This type provides information about added, deleted, + modified and temporary VNFCs. + type: object + required: + - id + - vduId + - changeType + - computeResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: > + Signals the type of change. Permitted values: * + ADDED * REMOVED * MODIFIED * TEMPORARY For a + temporary resource, an AffectedVnfc structure exists + as long as the temporary resource exists. + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + affectedVnfcCpIds: + description: > + Identifiers of CP(s) of the VNFC instance that were + affected by the change. Shall be present for those + affected CPs of the VNFC instance that are + associated to an external CP of the VNF instance. + May be present for further affected CPs of the VNFC + instance. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + addedStorageResourceIds: + description: > + References to VirtualStorage resources that have + been added. Each value refers to a + VirtualStorageResourceInfo item in the VnfInstance + that was added to the VNFC. It shall be provided if + at least one storage resource was added to the VNFC. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + removedStorageResourceIds: + description: > + References to VirtualStorage resources that have + been removed. The value contains the identifier of a + VirtualStorageResourceInfo item that has been + removed from the VNFC, and might no longer exist in + the VnfInstance. It shall be provided if at least + one storage resource was removed from the VNFC. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + affectedVirtualLinks: + description: > + Information about VL instances that were affected during + the lifecycle operation. See note 1 and note 3. + type: array + items: + description: "This type provides information about added, deleted, modified and temporary VLs, and added or removed VNF link ports.\nNOTE:\tWhen signalling the addition (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) of VNF link ports, \n the \"networkResource\" attribute refers to the affected virtual link instance, not the link port \n instance. The resource handles of the affected VNF link ports can be found by dereferencing the \n identifiers in the \"vnfLinkPortIds\" attribute.\n" + type: object + required: + - id + - vnfVirtualLinkDescId + - changeType + - networkResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: > + Signals the type of change. Permitted values: * + ADDED * REMOVED * MODIFIED * TEMPORARY * + LINK_PORT_ADDED * LINK_PORT_REMOVED For a temporary + resource, an AffectedVirtualLink structure exists as + long as the temporary resource exists. When + signalling the addition (LINK_PORT_ADDED) or removal + (LINK_PORT_REMOVED) of VNF link ports, the + "networkResource" attribute refers to the affected + virtual link instance, not the link port instance. + The resource handles of the affected VNF link ports + can be found by dereferencing the identifiers in the + "vnfLinkPortIds" attribute. + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + - LINK_PORT_ADDED + - LINK_PORT_REMOVED + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + vnfLinkPortIds: + description: > + Identifiers of the link ports of the affected VL + related to the change. Each identifier references a + "VnfLinkPortInfo" structure. + + Shall be set when changeType is equal to + "LINK_PORT_ADDED" or "LINK_PORT_REMOVED", and the + related "VnfLinkPortInfo" structures are present + (case "added") or have been present (case "removed") + in the "VnfVirtualLinkResourceInfo" or + "ExtManagedVirtualLinkInfo" structures that are + represented by the "vnfVirtualLinkResourceInfo" or + "extManagedVirtualLinkInfo" attribute in the + "VnfInstance" structure. See note. + type: array + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + affectedExtLinkPorts: + description: > + Information about external VNF link ports that were + affected during the lifecycle operation. See note 1. + type: array + items: + description: > + This type provides information about added and deleted + external link ports (link ports attached to external + virtual links). + type: object + required: + - id + - changeType + - extCpInstanceId + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: "Signals the type of change. Permitted values: -\tADDED - MODIFIED -\tREMOVED\n" + type: string + enum: + - ADDED + - MODIFIED + - REMOVED + extCpInstanceId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + affectedVirtualStorages: + description: > + Information about virtualised storage instances that were + affected during the lifecycle operation. See note 1. + type: array + items: + description: > + This type provides information about added, deleted, + modified and temporary virtual storage resources. + type: object + required: + - id + - virtualStorageDescId + - changeType + - storageResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: > + Signals the type of change. Permitted values: * + ADDED * REMOVED * MODIFIED * TEMPORARY For a + temporary resource, an AffectedVirtualStorage + structure exists as long as the temporary resource + exists. + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + changedInfo: + description: "This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource. The attributes that can be included consist of those requested to be modified explicitly in the \"VnfInfoModificationRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly e.g. when modifying the referenced VNF package. * NOTE:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute)\n was modified implicitly following a request to modify the \"vnfdId\" attribute, by\n copying the value of this attribute from the VNFD in the VNF Package identified\n by the \"vnfdId\" attribute.\n" + type: object + properties: + vnfInstanceName: + description: > + If present, this attribute signals modifications of the + "vnfInstanceName" attribute in "VnfInstance" as defined in + clause 5.5.2.12.. + type: string + vnfInstanceDescription: + description: > + If present, this attribute signals modifications of the + "vnfInstanceDescription" attribute in "VnfInstance", as + defined in clause 5.5.2.12.. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfProvider: + description: > + If present, this attribute signals modifications of the + "vnfProvider" attribute in "VnfInstance". See note. + type: string + vnfProductName: + description: > + If present, this attribute signals modifications of the + "vnfProductName" attribute in "VnfInstance". See note. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vnfcInfoModifications: + description: > + If present, this attribute signals modifications of + certain entries in the "vnfcInfo" attribute array in the + "instantiatedVnfInfo" attribute of "VnfInstance", as + defined in clause 5.5.2.12. + type: array + items: + description: "This type represents modifications of an entry in an array of \"VnfcInfo\" objects. * NOTE:\tThe attribute \"id\" in this data type represents the same identifier as the attribute\n \"vnfcInstanceId\" in other related data types in the present document. For reasons of backward\n compatibility, this misalignment is not corrected.\n" + type: object + required: + - id + - vnfcConfigurableProperties + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfcConfigurableProperties: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + affectedVipCps: + description: > + Information about virtual IP CP instances that were affected + during the execution of the lifecycle management operation. + type: array + items: + description: > + This type provides information about added, deleted and + modified virtual IP CP instances. + type: object + required: + - cpInstanceId + - cpdId + - changeType + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: "Signals the type of change. Permitted values: -\tADDED -\tREMOVED -\tMODIFIED\n" + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + changedExtConnectivity: + description: > + Information about changed external connectivity, if + applicable. See note 1. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is known + to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service is a + Kubernetes® instance the resourceId shall be populated + in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the current CP + configuration information for the connection of external + CPs to the external virtual link. See note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. The + entries shall be applied by the VNFM according to + the rules of JSON Merge Patch (see IETF RFC 7396). + See notes 2, 3, 4, 5 and 6. In case of deleting an + external CP, the list of instances to be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the + CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored. + + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + extNetAttDefResource: + description: > + Network attachment definition resources that provide the + specification of the interface to attach connection + points to this VL. + type: array + items: + description: > + This type contains information related to a network + attachment definition resource that provides the + specification of the interface used to connect one or + multiple connection points to a secondary container + cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of being globally + unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated to this + network attachment definition resource. Shall be + present when the network attachment definition + resource is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to this + network attachment definition resource. May be + present when the network attachment definition + resource is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + routingResource: + description: > + Network resources that provide the forwarding/routing + capabilities associated to the network resource + realizing this VL. + type: array + items: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service is + a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the CISM + and shall be absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + modificationsTriggeredByVnfPkgChange: + description: "This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource when changing the current VNF package. The attributes that can be included consist of those requested to be modified explicitly in the \"ChangeCurrentVnfPkgRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly during the operation.\nNOTE 1:\tThis attribute represents the delta (semantics as per IETF RFC 7396, JSON Merge Patch) between the value \n of the attribute at the start of the \"Change current VNF package\" operation and the value of the attribute \n at its completion.\nNOTE 2:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) was modified implicitly \n during the related operation and contains a copy of the value of the related attribute from the VNFD in the \n VNF Package identified by the \"vnfdId\" attribute.\n" + type: object + properties: + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfProvider: + description: > + If present, this attribute signals the new value of the + "vnfProvider" attribute in "VnfInstance". See note 2. + type: string + vnfProductName: + description: > + If present, this attribute signals the new value of the + "vnfProductName" attribute in "VnfInstance". See note 2. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vnfSnapshotInfoId: + description: | + An identifier with the intention of being globally unique. + type: string + lcmCoordinations: + description: > + Information about LCM coordination actions (see clause 10) + related to this LCM operation occurrence. + type: object + required: + - id + - coordinationActionName + - startTime + - endpointType + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + coordinationActionName: + description: | + An identifier with the intention of being globally unique. + type: string + coordinationResult: + description: > + The enumeration LcmCoordResultType defines the permitted + values to represent the result of executing an LCM + coordination action. The coordination result also implies + the action to be performed by the VNFM as the follow-up to + this coordination. Value | Description ------|------------ + CONTINUE | The related LCM operation shall be continued, + staying in the state "PROCESSING". ABORT | The related LCM + operation shall be aborted by transitioning into the state + "FAILED_TEMP". CANCELLED | The coordination action has + been cancelled upon request of the API consumer, i.e. the + VNFM. The related LCM operation shall be aborted by + transitioning into the state "FAILED_TEMP". + type: string + enum: + - CONTINUE + - ABORT + - CANCELLED + startTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + endTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + endpointType: + description: > + The endpoint type used by this coordination action. Valid + values: - MGMT: coordination with other operation + supporting management systems (e.g. EM) - VNF: + coordination with the VNF instance + type: string + enum: + - MGMT + - VNF + delay: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + rejectedLcmCoordinations: + description: > + Information about LCM coordination actions (see clause 10) + that were rejected by 503 error which means they will be tried + again after a delay. See note 5. + type: object + required: + - coordinationActionName + - rejectionTime + - endpointType + - delay + properties: + coordinationActionName: + description: | + An identifier with the intention of being globally unique. + type: string + rejectionTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + endpointType: + description: > + The endpoint type used by this coordination action. Valid + values: - MGMT: coordination with other operation + supporting management systems (e.g. EM) - VNF: + coordination with the VNF instance + type: string + enum: + - MGMT + - VNF + delay: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + warnings: + description: > + Warning messages that were generated while the operation was + executing. + + If the operation has included LCM coordination actions and + these have resulted in warnings, such warnings should be added + to this attribute. + type: array + items: + type: string + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + - vnfInstance + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + grant: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + cancel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + retry: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + rollback: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + fail: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + VnfLcmOpOccFail.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the VNF LCM operation + occurrence. + Typically, this is due to the fact that the VNF LCM + operation occurrence is not in FAILED_TEMP state or + another error handling action is starting such as retry + or rollback. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + VnfLcmOpOccCancel.Post.202: + description: > + 202 ACCEPTED + + The request has been accepted for processing, but processing has not + been completed. The response shall + + have an empty message content. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + content: {} + VnfLcmOpOccCancel.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the VNF LCM operation + occurrence. + Typically, this is due to the fact that the operation + occurrence is not in STARTING, PROCESSING or + ROLLING_BACK state. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + Subscriptions.Get.200: + description: > + 200 OK + + Shall be returned when the list of subscriptions has been queried + successfully. + + The response body shall contain in an array the representations of all + active subscriptions of + + the functional block that invokes the method, i.e. zero or more + representations of lifecycle change + + notification subscriptions as defined in clause 5.5.2.16. + + If the "filter" URI parameter was supplied in the request, the data in + the response body shall have been + + transformed according to the rules specified in clause 5.2.2 of ETSI GS + NFV-SOL 013. + + If the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 + of ETSI GS NFV-SOL 013 + + for this resource, inclusion of the Link HTTP header in this response + shall follow the provisions + + in clause 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + This type represents a subscription related to notifications about + VNF lifecycle changes. + type: object + required: + - id + - callbackUri + - verbosity + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: "This type represents a subscription filter related to notifications about VNF lifecycle changes.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of \n the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdIds + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId values + listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, from + one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tVnfLcmOperationOccurrenceNotification -\tVnfIdentifierCreationNotification -\tVnfIdentifierDeletionNotification See note.\n" + type: array + items: + type: string + enum: + - VnfLcmOperationOccurrenceNotification + - VnfIdentifierCreationNotification + - VnfIdentifierDeletionNotification + operationTypes: + description: > + Match particular VNF lifecycle operation types for the + notification of type + VnfLcmOperationOccurrenceNotification. May be present if + the "notificationTypes" attribute contains the value + "VnfLcmOperationOccurrenceNotification", and shall be + absent otherwise. + type: array + items: + description: > + The enumeration LcmOpType defines the permitted values + to represent VNF lifecycle operation types in VNF + lifecycle management operation occurrence resources and + VNF lifecycle management operation occurrence + notifications. + + Value | Description ------|------------ INSTANTIATE | + Represents the "Instantiate VNF" LCM operation. SCALE + | Represents the "Scale VNF" LCM operation. + SCALE_TO_LEVEL | Represents the "Scale VNF to Level" LCM + operation. CHANGE_FLAVOUR | Represents the "Change VNF + Flavour" LCM operation. TERMINATE | Represents the + "Terminate VNF" LCM operation. HEAL | Represents the + "Heal VNF" LCM operation. OPERATE | Represents the + "Operate VNF" LCM operation. CHANGE_EXT_CONN | + Represents the "Change external VNF connectivity" LCM + operation. MODIFY_INFO | Represents the "Modify VNF + Information" LCM operation. CREATE_SNAPSHOT | Represents + the "Create VNF Snapshot" LCM operation. + REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF + Snapshot" LCM operation. CHANGE_VNFPKG | Represents the + "Change current VNF package" LCM operation. + SELECT_DEPL_MODS | Represents the "Select VNF + deployable modules" LCM operation + type: string + enum: + - INSTANTIATE + - SCALE + - SCALE_TO_LEVEL + - CHANGE_FLAVOUR + - TERMINATE + - HEAL + - OPERATE + - CHANGE_EXT_CONN + - MODIFY_INFO + - CREATE_SNAPSHOT + - REVERT_TO_SNAPSHOT + - CHANGE_VNFPKG + - SELECT_DEPL_MODS + operationStates: + description: > + Match particular LCM operation state values as reported in + notifications of type + VnfLcmOperationOccurrenceNotification. May be present if + the "notificationTypes" attribute contains the value + "VnfLcmOperationOccurrenceNotification", and shall be + absent otherwise. + type: array + items: + description: > + STARTING: The LCM operation is starting. PROCESSING: The + LCM operation is currently in execution. COMPLETED: The + LCM operation has been completed successfully. + FAILED_TEMP: The LCM operation has failed and execution + has stopped, but the execution of the operation is not + considered to be closed. FAILED: The LCM operation has + failed and it cannot be retried or rolled back, as it is + determined that such action won't succeed. ROLLING_BACK: + The LCM operation is currently being rolled back. + ROLLED_BACK: The LCM operation has been successfully + rolled back, i.e. The state of the VNF prior to the + original operation invocation has been restored as + closely as possible. + type: string + enum: + - STARTING + - PROCESSING + - COMPLETED + - FAILED_TEMP + - FAILED + - ROLLING_BACK + - ROLLED_BACK + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + verbosity: + description: > + The enumeration LcmOpOccNotificationVerbosityType provides + values to control the verbosity of LCM operation occurrence + notifications. * FULL: This signals a full notification which + contains all change details. * SHORT: This signals a short + notification which omits large-volume change details to reduce + the size of data to + be sent via the notification mechanism. + type: string + enum: + - FULL + - SHORT + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + Subscriptions.Post.201: + description: > + 201 CREATED + + The subscription has been created successfully. The response body shall + contain a representation of the + + created "Individual subscription" resource. The HTTP response shall + include a "Location" HTTP header that points + + to the created "Individual subscription" resource. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: The resource URI of the created VNF instance + style: simple + explode: false + schema: + type: string + format: url + content: + application/json: + schema: + description: > + This type represents a subscription related to notifications about + VNF lifecycle changes. + type: object + required: + - id + - callbackUri + - verbosity + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: "This type represents a subscription filter related to notifications about VNF lifecycle changes.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of \n the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdIds + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId values + listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, from + one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tVnfLcmOperationOccurrenceNotification -\tVnfIdentifierCreationNotification -\tVnfIdentifierDeletionNotification See note.\n" + type: array + items: + type: string + enum: + - VnfLcmOperationOccurrenceNotification + - VnfIdentifierCreationNotification + - VnfIdentifierDeletionNotification + operationTypes: + description: > + Match particular VNF lifecycle operation types for the + notification of type + VnfLcmOperationOccurrenceNotification. May be present if + the "notificationTypes" attribute contains the value + "VnfLcmOperationOccurrenceNotification", and shall be + absent otherwise. + type: array + items: + description: > + The enumeration LcmOpType defines the permitted values + to represent VNF lifecycle operation types in VNF + lifecycle management operation occurrence resources and + VNF lifecycle management operation occurrence + notifications. + + Value | Description ------|------------ INSTANTIATE | + Represents the "Instantiate VNF" LCM operation. SCALE + | Represents the "Scale VNF" LCM operation. + SCALE_TO_LEVEL | Represents the "Scale VNF to Level" LCM + operation. CHANGE_FLAVOUR | Represents the "Change VNF + Flavour" LCM operation. TERMINATE | Represents the + "Terminate VNF" LCM operation. HEAL | Represents the + "Heal VNF" LCM operation. OPERATE | Represents the + "Operate VNF" LCM operation. CHANGE_EXT_CONN | + Represents the "Change external VNF connectivity" LCM + operation. MODIFY_INFO | Represents the "Modify VNF + Information" LCM operation. CREATE_SNAPSHOT | Represents + the "Create VNF Snapshot" LCM operation. + REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF + Snapshot" LCM operation. CHANGE_VNFPKG | Represents the + "Change current VNF package" LCM operation. + SELECT_DEPL_MODS | Represents the "Select VNF + deployable modules" LCM operation + type: string + enum: + - INSTANTIATE + - SCALE + - SCALE_TO_LEVEL + - CHANGE_FLAVOUR + - TERMINATE + - HEAL + - OPERATE + - CHANGE_EXT_CONN + - MODIFY_INFO + - CREATE_SNAPSHOT + - REVERT_TO_SNAPSHOT + - CHANGE_VNFPKG + - SELECT_DEPL_MODS + operationStates: + description: > + Match particular LCM operation state values as reported in + notifications of type + VnfLcmOperationOccurrenceNotification. May be present if + the "notificationTypes" attribute contains the value + "VnfLcmOperationOccurrenceNotification", and shall be + absent otherwise. + type: array + items: + description: > + STARTING: The LCM operation is starting. PROCESSING: The + LCM operation is currently in execution. COMPLETED: The + LCM operation has been completed successfully. + FAILED_TEMP: The LCM operation has failed and execution + has stopped, but the execution of the operation is not + considered to be closed. FAILED: The LCM operation has + failed and it cannot be retried or rolled back, as it is + determined that such action won't succeed. ROLLING_BACK: + The LCM operation is currently being rolled back. + ROLLED_BACK: The LCM operation has been successfully + rolled back, i.e. The state of the VNF prior to the + original operation invocation has been restored as + closely as possible. + type: string + enum: + - STARTING + - PROCESSING + - COMPLETED + - FAILED_TEMP + - FAILED + - ROLLING_BACK + - ROLLED_BACK + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + verbosity: + description: > + The enumeration LcmOpOccNotificationVerbosityType provides + values to control the verbosity of LCM operation occurrence + notifications. * FULL: This signals a full notification which + contains all change details. * SHORT: This signals a short + notification which omits large-volume change details to reduce + the size of data to + be sent via the notification mechanism. + type: string + enum: + - FULL + - SHORT + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + Subscriptions.Post.422: + description: > + 422 Unprocessable Content + + + Shall be returned upon the following error: The content type of the + message content is supported + + and the message content of a request contains syntactically correct data + but the data cannot be + + processed. + + The general cause for this error and its handling is specified in clause + 6.4 of ETSI GS NFV-SOL 013, + + including rules for the presence of the response body. + + Specifically in case of this resource, the response code 422 shall also + be returned if the VNFM has + + tested the Notification endpoint as described in clause 5.4.20.3.2 and + the test has failed. + + In this case, the "detail" attribute in the "ProblemDetails" structure + shall convey more + + information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: Version of the API used in the response. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualSubscription.Get.200: + description: > + 200 OK + + The operation has completed successfully. The response body shall + contain a representation of the + + "Individual subscription" resource. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + This type represents a subscription related to notifications about + VNF lifecycle changes. + type: object + required: + - id + - callbackUri + - verbosity + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: "This type represents a subscription filter related to notifications about VNF lifecycle changes.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of \n the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdIds + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId values + listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, from + one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tVnfLcmOperationOccurrenceNotification -\tVnfIdentifierCreationNotification -\tVnfIdentifierDeletionNotification See note.\n" + type: array + items: + type: string + enum: + - VnfLcmOperationOccurrenceNotification + - VnfIdentifierCreationNotification + - VnfIdentifierDeletionNotification + operationTypes: + description: > + Match particular VNF lifecycle operation types for the + notification of type + VnfLcmOperationOccurrenceNotification. May be present if + the "notificationTypes" attribute contains the value + "VnfLcmOperationOccurrenceNotification", and shall be + absent otherwise. + type: array + items: + description: > + The enumeration LcmOpType defines the permitted values + to represent VNF lifecycle operation types in VNF + lifecycle management operation occurrence resources and + VNF lifecycle management operation occurrence + notifications. + + Value | Description ------|------------ INSTANTIATE | + Represents the "Instantiate VNF" LCM operation. SCALE + | Represents the "Scale VNF" LCM operation. + SCALE_TO_LEVEL | Represents the "Scale VNF to Level" LCM + operation. CHANGE_FLAVOUR | Represents the "Change VNF + Flavour" LCM operation. TERMINATE | Represents the + "Terminate VNF" LCM operation. HEAL | Represents the + "Heal VNF" LCM operation. OPERATE | Represents the + "Operate VNF" LCM operation. CHANGE_EXT_CONN | + Represents the "Change external VNF connectivity" LCM + operation. MODIFY_INFO | Represents the "Modify VNF + Information" LCM operation. CREATE_SNAPSHOT | Represents + the "Create VNF Snapshot" LCM operation. + REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF + Snapshot" LCM operation. CHANGE_VNFPKG | Represents the + "Change current VNF package" LCM operation. + SELECT_DEPL_MODS | Represents the "Select VNF + deployable modules" LCM operation + type: string + enum: + - INSTANTIATE + - SCALE + - SCALE_TO_LEVEL + - CHANGE_FLAVOUR + - TERMINATE + - HEAL + - OPERATE + - CHANGE_EXT_CONN + - MODIFY_INFO + - CREATE_SNAPSHOT + - REVERT_TO_SNAPSHOT + - CHANGE_VNFPKG + - SELECT_DEPL_MODS + operationStates: + description: > + Match particular LCM operation state values as reported in + notifications of type + VnfLcmOperationOccurrenceNotification. May be present if + the "notificationTypes" attribute contains the value + "VnfLcmOperationOccurrenceNotification", and shall be + absent otherwise. + type: array + items: + description: > + STARTING: The LCM operation is starting. PROCESSING: The + LCM operation is currently in execution. COMPLETED: The + LCM operation has been completed successfully. + FAILED_TEMP: The LCM operation has failed and execution + has stopped, but the execution of the operation is not + considered to be closed. FAILED: The LCM operation has + failed and it cannot be retried or rolled back, as it is + determined that such action won't succeed. ROLLING_BACK: + The LCM operation is currently being rolled back. + ROLLED_BACK: The LCM operation has been successfully + rolled back, i.e. The state of the VNF prior to the + original operation invocation has been restored as + closely as possible. + type: string + enum: + - STARTING + - PROCESSING + - COMPLETED + - FAILED_TEMP + - FAILED + - ROLLING_BACK + - ROLLED_BACK + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + verbosity: + description: > + The enumeration LcmOpOccNotificationVerbosityType provides + values to control the verbosity of LCM operation occurrence + notifications. * FULL: This signals a full notification which + contains all change details. * SHORT: This signals a short + notification which omits large-volume change details to reduce + the size of data to + be sent via the notification mechanism. + type: string + enum: + - FULL + - SHORT + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualSubscription.Delete.204: + description: > + 204 NO CONTENT + + The "Individual subscription" resource has been deleted successfully. + The response body shall be empty. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + content: {} + VnfInstanceCreateSnapshot.Post.202: + description: > + 202 ACCEPTED + + Shall be returned when the request was accepted for processing, but the + processing has not been completed. + + The response body shall be empty. The HTTP response shall include a + "Location" HTTP header that contains the URI + + of the newly-created "VNF LCM operation occurrence" resource + corresponding to the operation. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: > + Used in redirection, or when a new resource has been created. This + header field shall be present if the + + response status code is 201 or 3xx. In the present document this + header field is also used if the response + + status code is 202 and a new resource was created. + style: simple + explode: false + schema: + type: string + format: url + content: {} + VnfInstanceCreateSnapshot.Post.404: + description: > + 404 Not Found + + + Shall be returned upon the following error: The API producer did not + find a current representation + + for the target resource or is not willing to disclose that one exists. + + The general cause for this error and its handling is specified in clause + 6.4 of ETSI + + GS NFV-SOL 013, including rules for the presence of the response body. + + Specifically in case of this task resource, the response code 404 shall + also be returned if the + + task is not supported for the VNF instance represented by the parent + resource, which means + + that the task resource consequently does not exist. + + In this case, the response body shall be present, and shall contain a + ProblemDetails structure, in + + which the "detail" attribute shall convey more information about the + error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: Version of the API used in the response. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + VnfInstanceCreateSnapshot.Post.409: + description: > + 409 CONFLICT + + + Shall be returned upon the following error: The operation cannot be + executed currently, due to a + + conflict with the state of the resource. + + Typically, this is due to the fact that the VNF instance resource is in + NOT_INSTANTIATED + + state, or that another lifecycle management operation is ongoing. + + The response body shall contain a ProblemDetails structure, in which the + "detail" attribute shall + + convey more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + VnfInstanceCreateSnapshot.Post.422: + description: > + 422 Unprocessable Content + + + Shall be returned upon the following error: The content type of the + message content is supported + + and the message content of a request contains syntactically correct data + but the data cannot be + + processed. + + The general cause for this error and its handling is specified in clause + 6.4 of ETSI + + GS NFV-SOL 013, including rules for the presence of the response body. + + Specifically in case of this resource, the response code 422 shall also + be returned if the provided + + identifier of the target "Individual VNF snapshot" resource for the VNF + snapshot is invalid. + + In this case, the "detail" attribute in the "ProblemDetails" structure + shall convey more + + information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: Version of the API used in the response. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + VnfInstanceRevertToSnapshot.Post.202: + description: > + 202 ACCEPTED + + Shall be returned when the request was accepted for processing, but the + processing has not been completed. + + The response body shall be empty. The HTTP response shall include a + "Location" HTTP header that contains the URI + + of the newly-created "VNF LCM operation occurrence" resource + corresponding to the operation. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: > + Used in redirection, or when a new resource has been created. This + header field shall be present if the + + response status code is 201 or 3xx. In the present document this + header field is also used if the response + + status code is 202 and a new resource was created. + style: simple + explode: false + schema: + type: string + format: url + content: {} + VnfInstanceRevertToSnapshot.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that the VNF + instance resource is in NOT_INSTANTIATED + state, or that another lifecycle management + operation is ongoing. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall + convey more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + VnfSnapshots.Post.201: + description: > + 201 CREATED + + Shall be returned when an individual VNF snapshot resource has been + created successfully. + + The response body shall contain a representation of the new individual + VNF snapshot resource, as defined in + + clause 5.5.2.21. The HTTP response shall include a "Location" HTTP + header that contains the resource URI of the + + individual VNF snapshot resource. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: > + Used in redirection, or when a new resource has been created. This + header field shall be present if the + + response status code is 201 or 3xx. In the present document this + header field is also used if the response + + status code is 202 and a new resource was created. + style: simple + explode: false + schema: + type: string + format: url + content: + application/json: + schema: + description: | + This type represents an individual VNF snapshot resource. + type: object + required: + - id + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfSnapshotPkgId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfSnapshot: + description: | + This type represents a VNF snapshot. + type: object + required: + - id + - vnfInstanceId + - triggeredAt + - vnfdId + - vnfInfo + - vnfcSnapshots + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + creationStartedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + creationFinishedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfInstance: + description: "This type represents a VNF instance. * NOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist\n between the previous and the newly referred VNF package, i.e. when the new VNFD is\n changed with respect to the previous VNFD in other aspects than merely referencing\n to other VNF software images. In order to avoid misalignment of the VnfInstance with\n the current VNF's on-boarded VNF package, the values of attributes in the VnfInstance\n that have corresponding attributes in the VNFD shall be kept in sync with the values in the VNFD.\n* NOTE 2:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 3:\tThese attributes are sometimes also referred to as configuration parameters\n applicable to a VNF. Some of these are set prior to instantiation and cannot be modified\n if the VNF is instantiated, some are set prior to instantiation (are part of initial configuration)\n and can be modified later, and others can be set only after instantiation.\n The applicability of certain configuration may depend on the VNF and the required operation of\n the VNF at a certain point in time.\n* NOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child\n attributes of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared\n in the VNFD with a defined initial value. The defined initial values can be declared in the VNFD,\n and/or, in case of \"metadata\", obtained from the \"CreateVnfRequest\" structure. Child attributes of\n \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that have no defined initial value shall\n not be created, in order to be consistent with the semantics of the JSON Merge Patch method\n (see IETF RFC 7396) that interprets null values as deletion request.\n* NOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case\n of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding\n to the same VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc\n and externally-managed multi-site VL instance (refer to clause 5.5.3.5).\n* NOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity,\n they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n* NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual extCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the VNF \n LCM operation explicitly indicates the scale level for the aspect.\n* NOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n" + type: object + required: + - id + - vnfdId + - vnfProvider + - vnfProductName + - vnfSoftwareVersion + - vnfdVersion + - instantiationState + - _links + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceName: + description: > + Name of the VNF instance. This attribute can be + modified with the PATCH method. + type: string + vnfInstanceDescription: + description: > + Human-readable description of the VNF instance. This + attribute can be modified with the PATCH method. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProvider: + description: > + Provider of the VNF and the VNFD. The value is copied + from the VNFD. + type: string + vnfProductName: + description: > + Name to identify the VNF Product. The value is copied + from the VNFD. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + certificateInfo: + description: > + This type provides input information related to + certificate and certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + certificateConfigurationInfo: + description: > + This type provides input information related to + certificate management. + type: object + required: + - securityPolicy + properties: + certificateBaseProfile: + description: > + This type provides input information to + override certificate base profile for + certificate management + + NOTE : At least one overriding attributes + shall be present, otherwise shall be absent. + required: + - id + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + issuer: + type: string + description: Issuer of certificates. See note. + issuerUniqueIdentifier: + description: > + An identifier with the intention of being + globally unique. + type: string + subject: + description: > + This type provides input information + related to subject of certificate. + + * NOTE: At least one overriding attributes + shall be present, otherwise shall be + absent. + type: object + properties: + commonName: + description: >- + Information of certification target + subject FQDN. See note. + type: string + organization: + description: >- + Information of certification target + subject Organization. See note. + type: string + country: + description: >- + Information of certification target + subject Country. See note. + type: string + state: + description: >- + Information of certification target + subject State. See note. + type: string + locality: + description: >- + Information of certification target + subject Locality. See note. + type: string + emailAddress: + description: >- + Information of certification contact + email address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of being + globally unique. + type: string + basicConstraints: + type: string + description: > + Basic constraints of certificates. See + note. + issuerAltName: + description: >- + Alternative name of issuer of certificates + in this NS. See note. + type: array + items: + type: string + subjectAltName: + description: >- + Alternative name of subject of + certificates. Shall be present when this + certificate is used for encrypted + communication using IP address and + subjectAltName attribute of + CertificateBaseProfile in CertificateDesc + of VNFD is empty (see ETSI GS NFV-IFA 011 + [7],clause 7.1.19.4). See note + type: array + items: + type: string + nameConstraints: + description: >- + Name constraints of certificates. See + note. + type: array + items: + type: string + securityPolicy: + description: > + Information for security policy to be + satisfied for certificate. + type: array + items: + description: > + This type provides input information related + to security policy for certificate + management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + maxValidityPeriod: + description: >- + Allowed max validity period for + certificates. + type: integer + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: integer + delegationSupportedCertificateManagements: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + cmfInfo: + description: > + This type provides input information related + to CMF for certificate management. + type: object + required: + - id + - endPoint + - supportedProtocol + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + endPoint: + description: End point of CMF instance. + type: object + required: + - ipAddress + - link + properties: + 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 + link: + description: > + This type represents a link to a + resource using an absolute URI. + type: object + required: + - href + properties: + href: + description: > + String formatted according to IETF RFC + 3986. + type: string + supportedProtocols: + description: Supported protocol by CMF instance. + type: array + items: + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + certificateChain: + description: Certificate chain that this CMF provides. + type: array + items: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + certificateContents: + description: > + Information for contents of issued certificates. + The information contained in this attribute may be + updated over time during the VNF LCM, e.g. + certificate(s) renewal. + type: array + items: + description: > + This type provides input information related to + certificate content. + type: object + required: + - id + - certificateDescId + - certificateType + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + certficateDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + certificateType: + description: Type of this certificate. + type: string + enum: + - VNFCI_CERT + - VNFOAM_CERT + supportedCertificateManagements: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + version: + description: | + A version. + type: string + serialNumber: + description: Serial number of this certificate. + type: integer + signatureAlgorithm: + description: Algorithm of this certificate's signature. + type: string + issuer: + description: Issuer of this certificate. + type: string + notBefore: + description: > + Date-time stamp. Representation: String + formatted according to IETF RFC 3339. + type: string + format: date-time + notAfter: + description: > + Date-time stamp. Representation: String + formatted according to IETF RFC 3339. + type: string + format: date-time + subject: + description: Subject of this certificate. + type: string + publicKeyAlgorithm: + description: Algorithm of this certificate's public key. + type: string + publicKey: + description: Public key of this certificate. + type: string + certificateExtensions: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + instantiationState: + description: | + The instantiation state of the VNF. + type: string + enum: + - NOT_INSTANTIATED + - INSTANTIATED + instantiatedVnfInfo: + description: > + Information specific to an instantiated VNF instance. + This attribute shall be present if the + instantiateState attribute value is INSTANTIATED. + type: object + required: + - flavourId + - vnfState + - extCpInfo + properties: + flavourId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfState: + description: > + STARTED: The VNF instance is up and running. + STOPPED: The VNF instance has been shut down. + type: string + enum: + - STARTED + - STOPPED + vnfPowerState: + description: > + This type represents information about the power + state of a VNF instance. + type: object + required: + - powerProfileId + - name + properties: + powerProfileId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + name: + description: > + Name of the power profile as provided in the + VNFD. + type: string + powerConsumptionInfo: + description: > + This type represents information about + estimated power consumption of the resources + associated with the power profile, as provided + in the VNFD. + type: object + required: + - minPowerConsumption + - maxPowerConsumption + - averagePowerConsumption + properties: + minPowerConsumption: + description: > + Minimum power consumption of this power + profile. Unit is KW/h. + type: integer + maxPowerConsumption: + description: > + Maximum power consumption of this power + profile. Unit is KW/h. + type: integer + averagePowerConsumption: + description: > + Average power consumption of this power + profile. Unit is KW/h. + type: integer + scaleStatus: + description: > + Scale status of the VNF, one entry per aspect. + Represents for every scaling aspect how "big" the + VNF has been scaled w.r.t. that aspect. This + attribute shall be present if the VNF supports + scaling. See clause B.2 for an explanation of VNF + scaling. For an aspect that has not been deployed + because the related deployableModule has not been + selected, it indicates the scale level that has + been requested in the instantiation or in a + scaling operation, or, if none has been requested + in any of them, the scale level applicable to the + aspect based on the default instantiation level. + See note 8. + type: array + items: + description: > + This type represents the scale level of a VNF + instance related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + scaleLevel: + description: > + Indicates the scale level. The minimum value + shall be 0 and the maximum value shall be <= + maxScaleLevel as described in the VNFD. + type: integer + maxScaleLevels: + description: > + Maximum allowed scale levels of the VNF, one entry + per aspect. This attribute shall be present if the + VNF supports scaling. + type: array + items: + description: > + This type represents the scale level of a VNF + instance related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + scaleLevel: + description: > + Indicates the scale level. The minimum value + shall be 0 and the maximum value shall be <= + maxScaleLevel as described in the VNFD. + type: integer + selectedDeployableModule: + description: > + References a currently selected deployable module, + as defined in the VNFD, that has already completed + the instantiation of its VNFCs + type: array + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + resourceCapacityDefinition: + description: > + Shows current values of VDU attributes related to + resource capacity, if different to the default + values from the VNFD, as indicated in the (one or + more) request(s) of all completed VNF LCM + operation(s) that contain this attribute. If an + attribute value has been modified multiple times, + only the last value is shown. The values + indicated in this attribute are applicable to all + VNFC instances based on the VDU to which the + resourceCapacityDefinition is related. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes. + + * NOTE: Resource definitions not related to a + VDU are not considered in this version of the + present document. + type: object + required: + - type + properties: + tag: + description: >- + Tag assigned by the issuer of a VNF LCM + operation request that contains this data + type with values to be applied to a VDU. It + is used for tracking purposes. The tag is + preserved in the run time record as long as + at least one value of the capacity related + attributes associated with that tag is still + valid, i.e., it has not been modified by a + later VNF LCM operation request. At most one + tag can be included when the data type is + used in a VNF LCM operation request. When + the data type is used in the VnfInstance + data type it may contain multiple tags, + namely those provided in VNF LCM requests, + if at least one of the values provided in + that request associated to that tag is still + applicable in the VNFCs created from this + VDU, i.e., it has not been modified by a + later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: "Type of the resource definition referenced. VALUES •\tCOMPUTE •\tSTORAGE •\tOSCONTAINER" + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + osContainerDescData: + description: >- + Indicates values for resource capacity + related attributes in an OsContainerDesc. It + shall be present when the attribute ‘type’ + indicates OSCONTAINER and absent otherwise. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes of an + OsContainer resource. + + * NOTE: At least one of the attributes + shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for + the container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for + the container expressed in the same + units as specified in the + requested_memory_resources_valid_values + property in VNFD for this container + descriptor. See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources + of the type indicated in the key. The + key is a string that identifies an + extended resource indicated in the + extended_resource_requests property in + the VNFD for this container descriptor. + The value is an integer that indicates + the required amount for a particular + extended resource.See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container + can maximally use in milli-CPU. See + note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required + for all the hugepages of the size + indicated in the key. The key is a + string and corresponds to one of the + values of the hugepage sizes indicated + in the huge_pages_resources property in + the VNFD for this container descriptor. + The value is a number that indicates the + required total size expressed in the + same units as in the + huge_pages_resources_property in the + VNFD that indicates the valid values for + required total size for the particular + hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power + state configuration data for the virtual + compute or OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU + cores are requested to be allocated to + logical CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states + of virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on + core utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for + capacity related VDU attributes of the + virtual compute resource of a VM. + + * NOTE: At least one of the attributes shall + be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - resourceTemplateId + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required + for all the hugepages of the size + indicated in the key. The key is a + string and corresponds to one of the + values of the hugepage sizes indicated + in the huge_pages_requirements property + in the VNFD for this virtual compute + descriptor. The value is a number that + indicates the required total size + expressed in the same units as in the + huge_pages_requirements property in the + VNFD that indicates the valid values for + required total size for the particular + hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power + state configuration data for the virtual + compute or OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU + cores are requested to be allocated to + logical CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states + of virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on + core utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size + related attribute in an VirtualStorageDesc. + It shall be present when the attribute + 'type' indicates STORAGE and absent + otherwise. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes of the + virtual storage resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + extCpInfo: + description: > + Information about the external CPs exposed by the + VNF instance. When trunking is enabled, the list + of entries includes both, external CPs + corresponding to parent ports of a trunk, and + external CPs associated to sub-ports of a trunk. + See note 7. + type: array + minItems: 1 + items: + description: "This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n" + type: object + required: + - id + - cpdId + - cpConfigId + - cpProtocolInfo + oneOf: + - required: + - associatedVnfcCpId + - required: + - associatedVipCpId + - required: + - associatedVnfVirtualLinkId + properties: + id: + 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 + cpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolInfo: + description: | + Network protocol information for this CP. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + extLinkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + associatedVnfcCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVipCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVirtualCpId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + associatedVnfVirtualLinkId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceInfo” + structure that provides the specification of + the interface to attach the connection point + to a secondary container cluster network. + See notes 3 and 4. It shall be present if + the external CP is associated to a VNFC + realized by one or a set of OS containers + and is connected to a secondary container + cluster network. It shall not be present + otherwise. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + certificateContentId: + description: > + An identifier with the intention of being + globally unique. + type: string + cpSecurityGroupInfo: + description: > + This type provides the list of active + security group rules applied to an external + CP instance. The type identifies which + "SecurityGroupRule" specified in the VNFD + are activated and the values of its + attributes. + type: object + required: + - securityGroupRuleId + - etherType + - protocol + - portRangeMin + - portRangeMax + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + description: + description: > + Human readable description of the + security group rule. + type: string + etherType: + description: > + Indicates the protocol carried over the + Ethernet layer. Permitted values: IPV4, + IPV6. + type: string + enum: + - IPV4 + - IPV6 + protocol: + description: > + Indicates the protocol carried over the + IP layer. Permitted values: any protocol + defined in the IANA protocol registry + (refer to clause 9.10.1.2 ofd ETSI GS + NFV-SOL 001 for further information). + type: string + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. + type: integer + vipCpInfo: + description: > + VIP CPs that are part of the VNF instance. Shall + be present when that particular VIP CP of the VNFC + instance is associated to an external CP of the + VNF instance. + + May be present otherwise. + type: array + items: + description: "This type provides information related to virtual IP CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n" + type: object + required: + - cpInstanceId + - cpdId + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There + shall be one cpProtocolInfo for layer 3. + There may be one cpProtocolInfo for layer 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + associatedVnfcCpIds: + description: > + Identifiers of the VnfcCps that share the + virtual IP address allocated to the VIP CP + instance. See note. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + virtualCpInfo: + description: > + Virtual CPs that are part of the VNF instance. + Shall be present when a particular virtual CP is + associated to an external CP of the VNF instance. + May be present otherwise. + type: array + items: + description: > + This type provides information related to a + virtual CP instance of a VNF. + + * NOTE 1: A consumer of the VNF LCM interface + can learn the actual VNFC instances implementing + the service + accessible via the virtual CP instance by querying the "vnfcResourceInfo" from the "InstantiatedVnfInfo" + and filtering by corresponding "vduIds" values. + * NOTE 2: The information can be omitted because + it is already available as part of the external + CP information in the + VnfExtCpInfo structure. + type: object + required: + - cpInstanceId + - cpdId + - resourceHandle + - vduIds + properties: + cpInstanceId: + 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 + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There + shall be one cpProtocolInfo for each layer + protocol supported. This attribute may be + omitted if the virtual CP is exposed as an + external CP. See note 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vduIds: + description: > + Reference to the VDU(s) which implement the + service accessible via the virtual CP + instance. See note. + type: array + minItems: 1 + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + additionalServiceInfo: + description: > + Additional service identification + information of the virtual CP instance. + type: array + items: + description: > + This type provides additional service + information of the virtual CP instance + used to expose properties of the virtual + CP to NFV-MANO. + + NOTE: This attribute shall only be present + if additional information is needed to + identify the service + termination within the VNF, such as for example a URL path information in an HTTP request required + to allow a single virtual CP IP address to be used for several HTTP based services that use the + same port number. + type: object + required: + - portInfo + properties: + portInfo: + description: > + Service port numbers exposed by the + virtual CP instance. + minItems: 1 + type: array + items: + description: > + This type describes the service + identifying port properties exposed by + the virtual CP instance. + type: object + required: + - name + - port + - portConfigurable + properties: + name: + description: > + The name of the port exposed by the + virtual CP instance. + type: string + protocol: + description: > + The L4 protocol for this port exposed by + the virtual CP instance. + + Permitted values: - TCP - UDP - SCTP + type: string + enum: + - TCP + - UDP + - SCTP + port: + description: > + The L4 port number exposed by the + virtual CP instance. + type: integer + portConfigurable: + description: > + The Boolean is a data type having two + values (true and false). + type: boolean + serviceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + extVirtualLinkInfo: + description: > + Information about the external VLs the VNF + instance is connected to. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM + or CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the current + CP configuration information for the + connection of external CPs to the external + virtual link. See note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be + configured on the CP instances created + from the respective CPD. The key of the + map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the + NFVO. The entries shall be applied by + the VNFM according to the rules of JSON + Merge Patch (see IETF RFC 7396). See + notes 2, 3, 4, 5 and 6. In case of + deleting an external CP, the list of + instances to be deleted. + type: object + additionalProperties: + description: > + This type represents an externally + provided link port, or a network + attachment definition resource of + secondary container cluster network, or + network address information per instance + of an external connection point. In the + case of VM-based deployment of the VNFC + exposing the external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based + deployment of the VNFC exposing the + external CP, the VNFM shall use the + network attachment definition resource + of secondary container cluster network + when connecting the CP to the external + VL. + + * NOTE 1: The following conditions apply + to the attributes "linkPortId" and + "cpProtocolData" for an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply + to the attributes “netAttDefResourceId” + and “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is + only applicable for specific cases where + more than one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but + not both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of + being globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create + a dedicated link port for the external + CP. If set to True, the VNFM shall + create a link port. If set to False, the + VNFM shall not create a link port. This + attribute is only applicable for + external CP instances without a floating + IP address that expose a VIP CP instance + for which a dedicated IP address is + allocated. It shall be present in that + case and shall be absent otherwise. + type: boolean + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects + the CP to a VL and the domain names for + the external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the + CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored. + + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security + groups. The parameters identify which + "SecurityGroupRule" specified in the + VNFD is activated/deactivated and for an + activated security group rule the values + of attributes defined in the VNFD that + can be overriden such as "portRangeMin" + and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceData” structure that + provides the specification of the + interface to attach the external CP to a + secondary container cluster network. It + is only applicable if the external CP is + connected or to be connected to a + secondary container cluster network. It + shall not be present if the external CP + is related to a virtual network not + categorized as secondary container + cluster network. See notes 2, 3 and 4. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + extNetAttDefResource: + description: > + Network attachment definition resources that + provide the specification of the interface + to attach connection points to this VL. + type: array + items: + description: > + This type contains information related to + a network attachment definition resource + that provides the specification of the + interface used to connect one or multiple + connection points to a secondary + container cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of + being globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM + or CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated + to this network attachment definition + resource. Shall be present when the + network attachment definition resource + is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to + this network attachment definition + resource. May be present when the + network attachment definition resource + is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + routingResource: + description: > + Network resources that provide the + forwarding/routing capabilities associated + to the network resource realizing this VL. + type: array + items: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be populated + in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + extManagedVirtualLinkInfo: + description: > + Information about the externally managed internal + VLs of the VNF instance. See note 5 and note 6. It + is possible to have several + ExtManagedVirtualLinkInfo for the same VNF + internal VL in case of a multi-site VNF spanning + several VIMs. The set of ExtManagedVirtualLinkInfo + corresponding to the same VNF internal VL shall + indicate so by referencing to the same + VnfVirtualLinkDesc and externally-managed + multi-site VL instance (refer to clause 5.5.3.5). + Even though externally-managed internal VLs are + also used for VNF-internal connectivity, they + shall not be listed in the + "vnfVirtualLinkResourceInfo" attribute as this + would be redundant. + type: array + items: + description: > + This type provides information about an + externally-managed virtual link. *NOTE: Both + vnfLinkPort and vnfNetAttDefResource can be + present in an ExtManagedVirtualLinkInfo to + indicate that + a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + vnfLinkPorts: + description: | + Link ports of this VL.See note. + type: array + items: + description: > + This type represents a link port of an + internal VL of a VNF. + + NOTE 1: Either cpInstanceId with + cpInstanceType set to "EXT_CP" or any + combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 + provides examples for configurations where + both vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is + scoped by the value of "vimConnectionId" + in the "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM + or CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vnfNetAttDefResource: + description: > + Network attachment definition resources that + provide the specification of the interface + to attach connection points to this VL. + type: array + items: + description: > + This type contains information related to + a network attachment definition resource + that provides the specification of the + interface used to connect one or multiple + connection points to a secondary + container cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of + being globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM + or CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated + to this network attachment definition + resource. Shall be present when the + network attachment definition resource + is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to + this network attachment definition + resource. May be present when the + network attachment definition resource + is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + routingResource: + description: > + Network resources that provide the + forwarding/routing capabilities associated + to the network resource realizing this VL. + type: array + items: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be populated + in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + monitoringParameters: + description: | + Active monitoring parameters. + type: array + items: + type: object + required: + - id + - performanceMetric + properties: + id: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + name: + description: > + Human readable name of the monitoring + parameter, as defined in the VNFD. + type: string + performanceMetric: + description: > + Performance metric that is monitored. This + attribute shall contain the related + "Measurement Name" value as defined in + clause 7.2 of ETSI GS NFV-IFA 027. + type: string + localizationLanguage: + description: > + Information about localization language of the VNF + (includes e.g. strings in the VNFD). The + localization languages supported by a VNF can be + declared in the VNFD, and localization language + selection can take place at instantiation time. + The value shall comply with the format defined in + IETF RFC 5646. + type: string + vnfcResourceInfo: + description: > + Information about the virtualised compute and + storage resources used by the VNFCs of the VNF + instance. + type: array + items: + description: "This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure \n of information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n - For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n - For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\n\n* NOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an internal VL that\n exposes an external CP. A VNFC CP is \"exposed as\" an external CP if it is connected directly\n to an external VL.\n* NOTE 3:\tThe information can be omitted because it is already available as part of the external CP information. * NOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\" structure by \n an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVnfc\"\n structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to \n this LCM operation occurrence.\n* NOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment \n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build \n a link redundant mated pair in SR-IOV cases.\n* NOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. * NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n" + type: object + required: + - id + - vduId + - computeResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + storageResourceIds: + description: > + References to the VirtualStorage resources + or references to Storage MCIO(s). The value + refers to a VirtualStorageResourceInfo item + in the VnfInstance. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfcCpInfo: + description: > + All the CPs of the VNFC instance. See note + 7. + type: array + items: + type: object + required: + - id + - cpdId + properties: + id: + 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 + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpProtocolInfo: + description: > + Network protocol information for this + CP. May be omitted if the VNFC CP is + exposed as an external CP. The + information can be omitted because it is + already available as part of the + external CP information. See note 3. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + parentCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceInfo” structure that + provides the specification of the + interface to attach the connection + point to a secondary container cluster + network. See notes 5 and 6. It shall be + present if the internal CP is associated + to a VNFC realized by one or a set of + OS containers and is connected to a + secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + certificateContentId: + description: > + Identifier(s) of the + "CertificateContent" structure that + provides the information of the + certificate(s) that this VNFC CP + instance uses. Shall be present when + using in delegation-mode. Otherwise + shall not be present. This attribute + shall be supported when delegation mode + in certificate management is applicable. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this VNFC CP + instance uses. Shall be present when using + in delegation-mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfVirtualLinkResourceInfo: + description: > + Information about the virtualised network + resources used by the VLs of the VNF instance. See + note 6. Even though externally-managed internal + VLs are also used for VNF-internal connectivity, + they shall not be listed in the + "vnfVirtualLinkResourceInfo" attribute as this + would be redundant. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used + by an internal VL instance in a VNF instance. + NOTE: If only the value or the presence of this + attribute is changed in the + "VnfVirtualLinkResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires including a + related "AffectedVirtualLink" structure in the VNF LCM operation occurrence notifications or the + "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + - vnfLinkPorts + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfLinkPorts: + description: > + Links ports of this VL. Shall be present + when the linkPort is used for external + connectivity by the VNF (refer to + VnfLinkPortInfo). May be present otherwise. + type: array + items: + description: > + This type represents a link port of an + internal VL of a VNF. + + NOTE 1: Either cpInstanceId with + cpInstanceType set to "EXT_CP" or any + combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 + provides examples for configurations where + both vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is + scoped by the value of "vimConnectionId" + in the "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM + or CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + virtualStorageResourceInfo: + description: > + Information on the virtualised storage resource(s) + used as storage for the VNF instance. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used + by a VNF instance. + + NOTE: If only the value or the presence of this + attribute is changed in the + "VirtualStorageResourceInfo" structure by an LCM + operation occurrence, this does not represent a + change that requires including a related + "AffectedVirtualStorage" structure in the VNF + LCM operation occurrence notifications or the + "VnfLcmOpOcc" structure related to this LCM + operation occurrence. + type: object + required: + - id + - virtualStorageDescId + - storageResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + vnfcInfo: + description: | + Information about the VNFC instances. + type: array + items: + description: "This type represents the information about a VNFC instance that is part of a VNF instance. * NOTE:\tThis allows to represent the error condition that a VNFC instance has lost its resources.\n" + type: object + required: + - id + - vduId + - vnfcState + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vduId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfcResourceInfoId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfcState: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfcConfigurableProperties: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + mcioInfo: + description: > + Information on the MCIO(s) representing VNFC + instance(s) realized by one or a set of OS + containers and created from the same VDU for the + VNF instance. + type: array + items: + description: > + This type provides information about an MCIO + representing the set of VNFC instances realized + by one or a set of OS containers which have + been created based on the same VDU. Within the + CISM, an MCIO controller monitors the actual + state of an MCIO representing the set of VNFC + instances realized by one or a set of OS + containers and compare it to the desired state. + For an MCIO related to a VDU that has the + attribute "isNumOfInstancesClusterBased" set to + FALSE the desired state is specified in the + respective declarative descriptor. For an MCIO + related to a VDU that has the attribute + "isNumOfInstancesClusterBased" set to TRUE, the + desired state is determined by the number of + CIS-nodes in the cluster that fulfil the VDU + requirements. It triggers actions toward the CIS + to align the actual to the desired state. + Monitoring the actual state includes monitoring + the number of MCIO instances available at any + specific point in time. In addition, an MCIO + controller maintains properties and runtime + information on the MCIO instances which have + been created based on the same VDU. The McioInfo + data structure provides the runtime information + on the MCIOs obtained from the MCIO controller. + + NOTE: There are different types of MCIOs. The + set of VNFC instances based on the same VDU is + represented + by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type + of MCIO, e.g. a POD. + + Runtime information of the set of OS containers + realizing an individual VNFC instance is not + part of the McioInfo data structure; such + runtime information is provided in the + ResourceHandle data structure referenced from + the VnfcResourceInfo. The McioInfo does not + provide runtime information of a constituent + VNFC instance created based on a specific VDU. + + NOTE 1: The type of MCIO as specified in the + declarative descriptor of the MCIO, and that can + be read from + the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the + “kind” property of the declarative descriptor. + NOTE 2: If the attribute additionalInfo is + present, it may contain runtime information on + the actual and + desired state of the MCIO(s). + NOTE 3: When the container infrastructure + service is a Kubernetes® instance, the mcioId is + the combined + values from the kind and name fields of the Kubernetes resource object, separated by a slash. + Example: "Deployment/abcd". + NOTE 4: When the container infrastructure + service is a Kubernetes® instance, the mcioName + is the name + field of the resource object. + type: object + required: + - mcioId + - mcioName + - mcioNamespace + - vduId + - cismId + - mcioType + - desiredInstances + - availableInstances + properties: + mcioId: + description: > + An identifier with the intention of being + globally unique. + type: string + mcioName: + description: > + Human readable name of this MCIO. See note + 4. + type: string + mcioNamespace: + description: | + Namespace of this MCIO. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cismId: + description: > + An identifier with the intention of being + globally unique. + type: string + mcioType: + description: > + The type of MCIO. Specific values, their + semantics and associated MCIO types are + defined in clause 5.5.4.9. Additional + values are also permitted. See note 1. + type: string + enum: + - Deployment + - StatefulSet + - DaemonSet + desiredInstances: + description: | + Number of desired MCIO instances. + type: integer + availableInstances: + description: | + Number of available MCIO instances. + type: integer + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + certificateContentId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfPaasServiceInfo: + description: > + Information on the PaaS Services assigned and used + by the VNF instance. + type: array + items: + description: > + This type provides information about a PaaS + Service that is used by a VNF instance. The + PaasServiceInfo is comprised of various sets of + information. Some information comes from the + VNFD, other information comes from the PaaS + Service assets provided by the NFVO to the VNFM, + and other information is provided at runtime + information about the usage of the PaaS Service. + type: object + required: + - id + - paasServiceId + - paasServiceType + - paasServiceRequestId + - paasServiceHandle + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being + globally unique. + type: string + paasServiceType: + description: > + The type of PaaS Service. The value of this + attribute is expected to be matched against + values of the registered PaaS Services in + the PSR. + type: string + paasServiceVersion: + description: | + A version. + type: string + paasServiceRequestId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + paasServiceHandle: + description: > + This type provides information enabling the + access and use of the PaaS Service by the + VNF instance. The type and format of the + handle depends on the form that the PaaS + Service is formed. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + indicators: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + instantiate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + terminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + heal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + operate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + createSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + revertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeCurrentVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperationLinks: + description: > + Links to the most recent LCM operation occurrences + related to this resource. See note 9. + type: object + properties: + recentVnfLcmOperation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmInstantiation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmTerminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmHeal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmModifyInfo: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmCreateSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmRevertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmSelectDplMods: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfcSnapshots: + description: > + Information about VNFC snapshots constituting this VNF + snapshot. + type: array + items: + description: "This type represents a VNFC snapshot. * NOTE 1:\tThe identifier of the compute snapshot resource is assigned during creation of a VNFC\n snapshot being returned from the VIM as output data in the response message of the individual\n resource operations. This attribute shall only be present for a VNFC snapshot that has been\n newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n NOTE 2:\tThe identifier of the storage snapshot resource is assigned during creation of a VNFC snapshot\n being returned from the VIM as output data in the response message of the individual resource\n operations. This attribute shall only be present for a VNFC snapshot with an associated storage\n resource and that has been newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n" + type: object + required: + - id + - vnfcInstanceId + - creationStartedAt + - vnfcResourceInfoId + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfcInstanceId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + creationStartedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + creationFinishedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + vnfcResourceInfoId: + description: "This type represents the information about a VNFC instance that is part of a VNF instance. * NOTE:\tThis allows to represent the error condition that a VNFC instance has lost its resources.\n" + type: object + required: + - id + - vduId + - vnfcState + properties: + id: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vduId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfcResourceInfoId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfcState: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfcConfigurableProperties: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + computeSnapshotResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + storageSnapshotResources: + description: > + Mapping of the storage resources associated to the + VNFC with the storage snapshot resources. + type: object + required: + - storageResourceId + properties: + storageResourceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + storageSnapshotResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used + by a VNF instance. Information about the + resource is available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id + is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See + note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the + VIM or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall + be absent otherwise. + type: string + userDefinedData: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + userDefinedData: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + takenFrom: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + VnfSnapshots.Get.200: + description: > + 200 OK + + Shall be returned when information about zero or more VNF snapshots was + queried successfully. + + The response body shall contain in an array the representations of zero + or more individual VNF + + snapshot resources, as defined in clause 5.5.2.21. + + + If the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 + of ETSI GS NFV-SOL 013 + + for this resource, inclusion of the Link HTTP header in this response + shall follow the provisions + + in clause 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: | + This type represents an individual VNF snapshot resource. + type: object + required: + - id + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfSnapshotPkgId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfSnapshot: + description: | + This type represents a VNF snapshot. + type: object + required: + - id + - vnfInstanceId + - triggeredAt + - vnfdId + - vnfInfo + - vnfcSnapshots + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceId: + description: > + An identifier with the intention of being globally + unique. + type: string + creationStartedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + creationFinishedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstance: + description: "This type represents a VNF instance. * NOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist\n between the previous and the newly referred VNF package, i.e. when the new VNFD is\n changed with respect to the previous VNFD in other aspects than merely referencing\n to other VNF software images. In order to avoid misalignment of the VnfInstance with\n the current VNF's on-boarded VNF package, the values of attributes in the VnfInstance\n that have corresponding attributes in the VNFD shall be kept in sync with the values in the VNFD.\n* NOTE 2:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 3:\tThese attributes are sometimes also referred to as configuration parameters\n applicable to a VNF. Some of these are set prior to instantiation and cannot be modified\n if the VNF is instantiated, some are set prior to instantiation (are part of initial configuration)\n and can be modified later, and others can be set only after instantiation.\n The applicability of certain configuration may depend on the VNF and the required operation of\n the VNF at a certain point in time.\n* NOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child\n attributes of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared\n in the VNFD with a defined initial value. The defined initial values can be declared in the VNFD,\n and/or, in case of \"metadata\", obtained from the \"CreateVnfRequest\" structure. Child attributes of\n \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that have no defined initial value shall\n not be created, in order to be consistent with the semantics of the JSON Merge Patch method\n (see IETF RFC 7396) that interprets null values as deletion request.\n* NOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case\n of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding\n to the same VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc\n and externally-managed multi-site VL instance (refer to clause 5.5.3.5).\n* NOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity,\n they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n* NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual extCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the VNF \n LCM operation explicitly indicates the scale level for the aspect.\n* NOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n" + type: object + required: + - id + - vnfdId + - vnfProvider + - vnfProductName + - vnfSoftwareVersion + - vnfdVersion + - instantiationState + - _links + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceName: + description: > + Name of the VNF instance. This attribute can be + modified with the PATCH method. + type: string + vnfInstanceDescription: + description: > + Human-readable description of the VNF instance. This + attribute can be modified with the PATCH method. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProvider: + description: > + Provider of the VNF and the VNFD. The value is + copied from the VNFD. + type: string + vnfProductName: + description: > + Name to identify the VNF Product. The value is + copied from the VNFD. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + certificateInfo: + description: > + This type provides input information related to + certificate and certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + certificateConfigurationInfo: + description: > + This type provides input information related to + certificate management. + type: object + required: + - securityPolicy + properties: + certificateBaseProfile: + description: > + This type provides input information to + override certificate base profile for + certificate management + + NOTE : At least one overriding attributes + shall be present, otherwise shall be absent. + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + issuer: + type: string + description: Issuer of certificates. See note. + issuerUniqueIdentifier: + description: > + An identifier with the intention of + being globally unique. + type: string + subject: + description: > + This type provides input information + related to subject of certificate. + + * NOTE: At least one overriding + attributes shall be present, otherwise + shall be absent. + type: object + properties: + commonName: + description: >- + Information of certification target + subject FQDN. See note. + type: string + organization: + description: >- + Information of certification target + subject Organization. See note. + type: string + country: + description: >- + Information of certification target + subject Country. See note. + type: string + state: + description: >- + Information of certification target + subject State. See note. + type: string + locality: + description: >- + Information of certification target + subject Locality. See note. + type: string + emailAddress: + description: >- + Information of certification contact + email address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of + being globally unique. + type: string + basicConstraints: + type: string + description: > + Basic constraints of certificates. See + note. + issuerAltName: + description: >- + Alternative name of issuer of + certificates in this NS. See note. + type: array + items: + type: string + subjectAltName: + description: >- + Alternative name of subject of + certificates. Shall be present when this + certificate is used for encrypted + communication using IP address and + subjectAltName attribute of + CertificateBaseProfile in + CertificateDesc of VNFD is empty (see + ETSI GS NFV-IFA 011 [7],clause + 7.1.19.4). See note + type: array + items: + type: string + nameConstraints: + description: >- + Name constraints of certificates. See + note. + type: array + items: + type: string + securityPolicy: + description: > + Information for security policy to be + satisfied for certificate. + type: array + items: + description: > + This type provides input information + related to security policy for certificate + management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + maxValidityPeriod: + description: >- + Allowed max validity period for + certificates. + type: integer + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: integer + delegationSupportedCertificateManagements: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + cmfInfo: + description: > + This type provides input information related + to CMF for certificate management. + type: object + required: + - id + - endPoint + - supportedProtocol + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + endPoint: + description: End point of CMF instance. + type: object + required: + - ipAddress + - link + properties: + 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 + link: + description: > + This type represents a link to a + resource using an absolute URI. + type: object + required: + - href + properties: + href: + description: > + String formatted according to IETF RFC + 3986. + type: string + supportedProtocols: + description: Supported protocol by CMF instance. + type: array + items: + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + certificateChain: + description: >- + Certificate chain that this CMF + provides. + type: array + items: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + certificateContents: + description: > + Information for contents of issued certificates. + The information contained in this attribute may + be updated over time during the VNF LCM, e.g. + certificate(s) renewal. + type: array + items: + description: > + This type provides input information related + to certificate content. + type: object + required: + - id + - certificateDescId + - certificateType + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + certficateDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + certificateType: + description: Type of this certificate. + type: string + enum: + - VNFCI_CERT + - VNFOAM_CERT + supportedCertificateManagements: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + version: + description: | + A version. + type: string + serialNumber: + description: Serial number of this certificate. + type: integer + signatureAlgorithm: + description: Algorithm of this certificate's signature. + type: string + issuer: + description: Issuer of this certificate. + type: string + notBefore: + description: > + Date-time stamp. Representation: String + formatted according to IETF RFC 3339. + type: string + format: date-time + notAfter: + description: > + Date-time stamp. Representation: String + formatted according to IETF RFC 3339. + type: string + format: date-time + subject: + description: Subject of this certificate. + type: string + publicKeyAlgorithm: + description: >- + Algorithm of this certificate's public + key. + type: string + publicKey: + description: Public key of this certificate. + type: string + certificateExtensions: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + instantiationState: + description: | + The instantiation state of the VNF. + type: string + enum: + - NOT_INSTANTIATED + - INSTANTIATED + instantiatedVnfInfo: + description: > + Information specific to an instantiated VNF + instance. This attribute shall be present if the + instantiateState attribute value is INSTANTIATED. + type: object + required: + - flavourId + - vnfState + - extCpInfo + properties: + flavourId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfState: + description: > + STARTED: The VNF instance is up and running. + STOPPED: The VNF instance has been shut down. + type: string + enum: + - STARTED + - STOPPED + vnfPowerState: + description: > + This type represents information about the power + state of a VNF instance. + type: object + required: + - powerProfileId + - name + properties: + powerProfileId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + name: + description: > + Name of the power profile as provided in the + VNFD. + type: string + powerConsumptionInfo: + description: > + This type represents information about + estimated power consumption of the resources + associated with the power profile, as + provided in the VNFD. + type: object + required: + - minPowerConsumption + - maxPowerConsumption + - averagePowerConsumption + properties: + minPowerConsumption: + description: > + Minimum power consumption of this power + profile. Unit is KW/h. + type: integer + maxPowerConsumption: + description: > + Maximum power consumption of this power + profile. Unit is KW/h. + type: integer + averagePowerConsumption: + description: > + Average power consumption of this power + profile. Unit is KW/h. + type: integer + scaleStatus: + description: > + Scale status of the VNF, one entry per aspect. + Represents for every scaling aspect how "big" + the VNF has been scaled w.r.t. that aspect. This + attribute shall be present if the VNF supports + scaling. See clause B.2 for an explanation of + VNF scaling. For an aspect that has not been + deployed because the related deployableModule + has not been selected, it indicates the scale + level that has been requested in the + instantiation or in a scaling operation, or, if + none has been requested in any of them, the + scale level applicable to the aspect based on + the default instantiation level. See note 8. + type: array + items: + description: > + This type represents the scale level of a VNF + instance related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + scaleLevel: + description: > + Indicates the scale level. The minimum + value shall be 0 and the maximum value + shall be <= maxScaleLevel as described in + the VNFD. + type: integer + maxScaleLevels: + description: > + Maximum allowed scale levels of the VNF, one + entry per aspect. This attribute shall be + present if the VNF supports scaling. + type: array + items: + description: > + This type represents the scale level of a VNF + instance related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + scaleLevel: + description: > + Indicates the scale level. The minimum + value shall be 0 and the maximum value + shall be <= maxScaleLevel as described in + the VNFD. + type: integer + selectedDeployableModule: + description: > + References a currently selected deployable + module, as defined in the VNFD, that has already + completed the instantiation of its VNFCs + type: array + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + resourceCapacityDefinition: + description: > + Shows current values of VDU attributes related + to resource capacity, if different to the + default values from the VNFD, as indicated in + the (one or more) request(s) of all completed + VNF LCM operation(s) that contain this + attribute. If an attribute value has been + modified multiple times, only the last value is + shown. The values indicated in this attribute + are applicable to all VNFC instances based on + the VDU to which the resourceCapacityDefinition + is related. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes. + + * NOTE: Resource definitions not related to a + VDU are not considered in this version of the + present document. + type: object + required: + - type + properties: + tag: + description: >- + Tag assigned by the issuer of a VNF LCM + operation request that contains this data + type with values to be applied to a VDU. + It is used for tracking purposes. The tag + is preserved in the run time record as + long as at least one value of the capacity + related attributes associated with that + tag is still valid, i.e., it has not been + modified by a later VNF LCM operation + request. At most one tag can be included + when the data type is used in a VNF LCM + operation request. When the data type is + used in the VnfInstance data type it may + contain multiple tags, namely those + provided in VNF LCM requests, if at least + one of the values provided in that request + associated to that tag is still applicable + in the VNFCs created from this VDU, i.e., + it has not been modified by a later + request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: "Type of the resource definition referenced. VALUES •\tCOMPUTE •\tSTORAGE •\tOSCONTAINER" + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + osContainerDescData: + description: >- + Indicates values for resource capacity + related attributes in an OsContainerDesc. + It shall be present when the attribute + ‘type’ indicates OSCONTAINER and absent + otherwise. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes of an + OsContainer resource. + + * NOTE: At least one of the attributes + shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for + the container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for + the container expressed in the same + units as specified in the + requested_memory_resources_valid_values + property in VNFD for this container + descriptor. See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources + of the type indicated in the key. The + key is a string that identifies an + extended resource indicated in the + extended_resource_requests property in + the VNFD for this container descriptor. + The value is an integer that indicates + the required amount for a particular + extended resource.See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container + can maximally use in milli-CPU. See + note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required + for all the hugepages of the size + indicated in the key. The key is a + string and corresponds to one of the + values of the hugepage sizes indicated + in the huge_pages_resources property in + the VNFD for this container descriptor. + The value is a number that indicates the + required total size expressed in the + same units as in the + huge_pages_resources_property in the + VNFD that indicates the valid values for + required total size for the particular + hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power + state configuration data for the virtual + compute or OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU + cores are requested to be allocated to + logical CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states + of virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on + core utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for + capacity related VDU attributes of the + virtual compute resource of a VM. + + * NOTE: At least one of the attributes + shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - resourceTemplateId + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required + for all the hugepages of the size + indicated in the key. The key is a + string and corresponds to one of the + values of the hugepage sizes indicated + in the huge_pages_requirements property + in the VNFD for this virtual compute + descriptor. The value is a number that + indicates the required total size + expressed in the same units as in the + huge_pages_requirements property in the + VNFD that indicates the valid values for + required total size for the particular + hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power + state configuration data for the virtual + compute or OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU + cores are requested to be allocated to + logical CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states + of virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on + core utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size + related attribute in an + VirtualStorageDesc. It shall be present + when the attribute 'type' indicates + STORAGE and absent otherwise. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes of the + virtual storage resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + extCpInfo: + description: > + Information about the external CPs exposed by + the VNF instance. When trunking is enabled, the + list of entries includes both, external CPs + corresponding to parent ports of a trunk, and + external CPs associated to sub-ports of a trunk. + See note 7. + type: array + minItems: 1 + items: + description: "This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n" + type: object + required: + - id + - cpdId + - cpConfigId + - cpProtocolInfo + oneOf: + - required: + - associatedVnfcCpId + - required: + - associatedVipCpId + - required: + - associatedVnfVirtualLinkId + properties: + id: + 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 + cpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolInfo: + description: | + Network protocol information for this CP. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + extLinkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + associatedVnfcCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVipCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVirtualCpId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + associatedVnfVirtualLinkId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceInfo” + structure that provides the specification + of the interface to attach the connection + point to a secondary container cluster + network. See notes 3 and 4. It shall be + present if the external CP is associated + to a VNFC realized by one or a set of OS + containers and is connected to a secondary + container cluster network. It shall not be + present otherwise. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + certificateContentId: + description: > + An identifier with the intention of being + globally unique. + type: string + cpSecurityGroupInfo: + description: > + This type provides the list of active + security group rules applied to an + external CP instance. The type identifies + which "SecurityGroupRule" specified in the + VNFD are activated and the values of its + attributes. + type: object + required: + - securityGroupRuleId + - etherType + - protocol + - portRangeMin + - portRangeMax + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + description: + description: > + Human readable description of the + security group rule. + type: string + etherType: + description: > + Indicates the protocol carried over the + Ethernet layer. Permitted values: IPV4, + IPV6. + type: string + enum: + - IPV4 + - IPV6 + protocol: + description: > + Indicates the protocol carried over the + IP layer. Permitted values: any protocol + defined in the IANA protocol registry + (refer to clause 9.10.1.2 ofd ETSI GS + NFV-SOL 001 for further information). + type: string + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. + type: integer + vipCpInfo: + description: > + VIP CPs that are part of the VNF instance. Shall + be present when that particular VIP CP of the + VNFC instance is associated to an external CP of + the VNF instance. + + May be present otherwise. + type: array + items: + description: "This type provides information related to virtual IP CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n" + type: object + required: + - cpInstanceId + - cpdId + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There + shall be one cpProtocolInfo for layer 3. + There may be one cpProtocolInfo for layer + 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + associatedVnfcCpIds: + description: > + Identifiers of the VnfcCps that share the + virtual IP address allocated to the VIP CP + instance. See note. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + virtualCpInfo: + description: > + Virtual CPs that are part of the VNF instance. + Shall be present when a particular virtual CP + is associated to an external CP of the VNF + instance. May be present otherwise. + type: array + items: + description: > + This type provides information related to a + virtual CP instance of a VNF. + + * NOTE 1: A consumer of the VNF LCM interface + can learn the actual VNFC instances + implementing the service + accessible via the virtual CP instance by querying the "vnfcResourceInfo" from the "InstantiatedVnfInfo" + and filtering by corresponding "vduIds" values. + * NOTE 2: The information can be omitted + because it is already available as part of the + external CP information in the + VnfExtCpInfo structure. + type: object + required: + - cpInstanceId + - cpdId + - resourceHandle + - vduIds + properties: + cpInstanceId: + 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 + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be populated + in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There + shall be one cpProtocolInfo for each layer + protocol supported. This attribute may be + omitted if the virtual CP is exposed as an + external CP. See note 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vduIds: + description: > + Reference to the VDU(s) which implement + the service accessible via the virtual CP + instance. See note. + type: array + minItems: 1 + items: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + additionalServiceInfo: + description: > + Additional service identification + information of the virtual CP instance. + type: array + items: + description: > + This type provides additional service + information of the virtual CP instance + used to expose properties of the + virtual CP to NFV-MANO. + + NOTE: This attribute shall only be + present if additional information is + needed to identify the service + termination within the VNF, such as for example a URL path information in an HTTP request required + to allow a single virtual CP IP address to be used for several HTTP based services that use the + same port number. + type: object + required: + - portInfo + properties: + portInfo: + description: > + Service port numbers exposed by the + virtual CP instance. + minItems: 1 + type: array + items: + description: > + This type describes the service + identifying port properties exposed by + the virtual CP instance. + type: object + required: + - name + - port + - portConfigurable + properties: + name: + description: > + The name of the port exposed by the + virtual CP instance. + type: string + protocol: + description: > + The L4 protocol for this port exposed by + the virtual CP instance. + + Permitted values: - TCP - UDP - SCTP + type: string + enum: + - TCP + - UDP + - SCTP + port: + description: > + The L4 port number exposed by the + virtual CP instance. + type: integer + portConfigurable: + description: > + The Boolean is a data type having two + values (true and false). + type: boolean + serviceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + extVirtualLinkInfo: + description: > + Information about the external VLs the VNF + instance is connected to. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be populated + in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM + or CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the + current CP configuration information for + the connection of external CPs to the + external virtual link. See note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be + configured on the CP instances created + from the respective CPD. The key of the + map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the + NFVO. The entries shall be applied by + the VNFM according to the rules of JSON + Merge Patch (see IETF RFC 7396). See + notes 2, 3, 4, 5 and 6. In case of + deleting an external CP, the list of + instances to be deleted. + type: object + additionalProperties: + description: > + This type represents an externally + provided link port, or a network + attachment definition resource of + secondary container cluster network, or + network address information per instance + of an external connection point. In the + case of VM-based deployment of the VNFC + exposing the external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based + deployment of the VNFC exposing the + external CP, the VNFM shall use the + network attachment definition resource + of secondary container cluster network + when connecting the CP to the external + VL. + + * NOTE 1: The following conditions apply + to the attributes "linkPortId" and + "cpProtocolData" for an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply + to the attributes “netAttDefResourceId” + and “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is + only applicable for specific cases where + more than one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but + not both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of + being globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create + a dedicated link port for the external + CP. If set to True, the VNFM shall + create a link port. If set to False, the + VNFM shall not create a link port. This + attribute is only applicable for + external CP instances without a floating + IP address that expose a VIP CP instance + for which a dedicated IP address is + allocated. It shall be present in that + case and shall be absent otherwise. + type: boolean + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects + the CP to a VL and the domain names for + the external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the + CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored. + + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security + groups. The parameters identify which + "SecurityGroupRule" specified in the + VNFD is activated/deactivated and for an + activated security group rule the values + of attributes defined in the VNFD that + can be overriden such as "portRangeMin" + and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceData” structure that + provides the specification of the + interface to attach the external CP to a + secondary container cluster network. It + is only applicable if the external CP is + connected or to be connected to a + secondary container cluster network. It + shall not be present if the external CP + is related to a virtual network not + categorized as secondary container + cluster network. See notes 2, 3 and 4. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + extNetAttDefResource: + description: > + Network attachment definition resources + that provide the specification of the + interface to attach connection points to + this VL. + type: array + items: + description: > + This type contains information related + to a network attachment definition + resource that provides the + specification of the interface used to + connect one or multiple connection + points to a secondary container cluster + network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of + being globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM + or CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated + to this network attachment definition + resource. Shall be present when the + network attachment definition resource + is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to + this network attachment definition + resource. May be present when the + network attachment definition resource + is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + routingResource: + description: > + Network resources that provide the + forwarding/routing capabilities associated + to the network resource realizing this VL. + type: array + items: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM + or CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + extManagedVirtualLinkInfo: + description: > + Information about the externally managed + internal VLs of the VNF instance. See note 5 and + note 6. It is possible to have several + ExtManagedVirtualLinkInfo for the same VNF + internal VL in case of a multi-site VNF spanning + several VIMs. The set of + ExtManagedVirtualLinkInfo corresponding to the + same VNF internal VL shall indicate so by + referencing to the same VnfVirtualLinkDesc and + externally-managed multi-site VL instance (refer + to clause 5.5.3.5). Even though + externally-managed internal VLs are also used + for VNF-internal connectivity, they shall not be + listed in the "vnfVirtualLinkResourceInfo" + attribute as this would be redundant. + type: array + items: + description: > + This type provides information about an + externally-managed virtual link. *NOTE: Both + vnfLinkPort and vnfNetAttDefResource can be + present in an ExtManagedVirtualLinkInfo to + indicate that + a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be populated + in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + vnfLinkPorts: + description: | + Link ports of this VL.See note. + type: array + items: + description: > + This type represents a link port of an + internal VL of a VNF. + + NOTE 1: Either cpInstanceId with + cpInstanceType set to "EXT_CP" or any + combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 + provides examples for configurations + where both vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" + is scoped by the value of + "vimConnectionId" in the + "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM + or CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vnfNetAttDefResource: + description: > + Network attachment definition resources + that provide the specification of the + interface to attach connection points to + this VL. + type: array + items: + description: > + This type contains information related + to a network attachment definition + resource that provides the + specification of the interface used to + connect one or multiple connection + points to a secondary container cluster + network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of + being globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM + or CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated + to this network attachment definition + resource. Shall be present when the + network attachment definition resource + is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to + this network attachment definition + resource. May be present when the + network attachment definition resource + is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + routingResource: + description: > + Network resources that provide the + forwarding/routing capabilities associated + to the network resource realizing this + VL. + type: array + items: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM + or CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + monitoringParameters: + description: | + Active monitoring parameters. + type: array + items: + type: object + required: + - id + - performanceMetric + properties: + id: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + name: + description: > + Human readable name of the monitoring + parameter, as defined in the VNFD. + type: string + performanceMetric: + description: > + Performance metric that is monitored. This + attribute shall contain the related + "Measurement Name" value as defined in + clause 7.2 of ETSI GS NFV-IFA 027. + type: string + localizationLanguage: + description: > + Information about localization language of the + VNF (includes e.g. strings in the VNFD). The + localization languages supported by a VNF can be + declared in the VNFD, and localization language + selection can take place at instantiation time. + The value shall comply with the format defined + in IETF RFC 5646. + type: string + vnfcResourceInfo: + description: > + Information about the virtualised compute and + storage resources used by the VNFCs of the VNF + instance. + type: array + items: + description: "This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure \n of information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n - For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n - For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\n\n* NOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an internal VL that\n exposes an external CP. A VNFC CP is \"exposed as\" an external CP if it is connected directly\n to an external VL.\n* NOTE 3:\tThe information can be omitted because it is already available as part of the external CP information. * NOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\" structure by \n an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVnfc\"\n structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to \n this LCM operation occurrence.\n* NOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment \n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build \n a link redundant mated pair in SR-IOV cases.\n* NOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. * NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n" + type: object + required: + - id + - vduId + - computeResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be populated + in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + storageResourceIds: + description: > + References to the VirtualStorage resources + or references to Storage MCIO(s). The + value refers to a + VirtualStorageResourceInfo item in the + VnfInstance. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfcCpInfo: + description: > + All the CPs of the VNFC instance. See note + 7. + type: array + items: + type: object + required: + - id + - cpdId + properties: + id: + 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 + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpProtocolInfo: + description: > + Network protocol information for this + CP. May be omitted if the VNFC CP is + exposed as an external CP. The + information can be omitted because it is + already available as part of the + external CP information. See note 3. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + parentCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceInfo” structure that + provides the specification of the + interface to attach the connection + point to a secondary container cluster + network. See notes 5 and 6. It shall be + present if the internal CP is associated + to a VNFC realized by one or a set of + OS containers and is connected to a + secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + certificateContentId: + description: > + Identifier(s) of the + "CertificateContent" structure that + provides the information of the + certificate(s) that this VNFC CP + instance uses. Shall be present when + using in delegation-mode. Otherwise + shall not be present. This attribute + shall be supported when delegation mode + in certificate management is applicable. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this VNFC CP + instance uses. Shall be present when using + in delegation-mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + vnfVirtualLinkResourceInfo: + description: > + Information about the virtualised network + resources used by the VLs of the VNF instance. + See note 6. Even though externally-managed + internal VLs are also used for VNF-internal + connectivity, they shall not be listed in the + "vnfVirtualLinkResourceInfo" attribute as this + would be redundant. + type: array + items: + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by an internal VL instance in a VNF + instance. NOTE: If only the value or the + presence of this attribute is changed in the + "VnfVirtualLinkResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires including a + related "AffectedVirtualLink" structure in the VNF LCM operation occurrence notifications or the + "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + - vnfLinkPorts + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be populated + in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfLinkPorts: + description: > + Links ports of this VL. Shall be present + when the linkPort is used for external + connectivity by the VNF (refer to + VnfLinkPortInfo). May be present + otherwise. + type: array + items: + description: > + This type represents a link port of an + internal VL of a VNF. + + NOTE 1: Either cpInstanceId with + cpInstanceType set to "EXT_CP" or any + combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 + provides examples for configurations + where both vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" + is scoped by the value of + "vimConnectionId" in the + "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM + or CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + virtualStorageResourceInfo: + description: > + Information on the virtualised storage + resource(s) used as storage for the VNF + instance. + type: array + items: + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. + + NOTE: If only the value or the presence of + this attribute is changed in the + "VirtualStorageResourceInfo" structure by an + LCM operation occurrence, this does not + represent a change that requires including a + related "AffectedVirtualStorage" structure in + the VNF LCM operation occurrence + notifications or the "VnfLcmOpOcc" structure + related to this LCM operation occurrence. + type: object + required: + - id + - virtualStorageDescId + - storageResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be populated + in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + vnfcInfo: + description: | + Information about the VNFC instances. + type: array + items: + description: "This type represents the information about a VNFC instance that is part of a VNF instance. * NOTE:\tThis allows to represent the error condition that a VNFC instance has lost its resources.\n" + type: object + required: + - id + - vduId + - vnfcState + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vduId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfcResourceInfoId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfcState: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfcConfigurableProperties: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + mcioInfo: + description: > + Information on the MCIO(s) representing VNFC + instance(s) realized by one or a set of OS + containers and created from the same VDU for + the VNF instance. + type: array + items: + description: > + This type provides information about an MCIO + representing the set of VNFC instances + realized by one or a set of OS containers + which have been created based on the same VDU. + Within the CISM, an MCIO controller monitors + the actual state of an MCIO representing the + set of VNFC instances realized by one or a + set of OS containers and compare it to the + desired state. For an MCIO related to a VDU + that has the attribute + "isNumOfInstancesClusterBased" set to FALSE + the desired state is specified in the + respective declarative descriptor. For an MCIO + related to a VDU that has the attribute + "isNumOfInstancesClusterBased" set to TRUE, + the desired state is determined by the number + of CIS-nodes in the cluster that fulfil the + VDU requirements. It triggers actions toward + the CIS to align the actual to the desired + state. Monitoring the actual state includes + monitoring the number of MCIO instances + available at any specific point in time. In + addition, an MCIO controller maintains + properties and runtime information on the + MCIO instances which have been created based + on the same VDU. The McioInfo data structure + provides the runtime information on the MCIOs + obtained from the MCIO controller. + + NOTE: There are different types of MCIOs. The + set of VNFC instances based on the same VDU is + represented + by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type + of MCIO, e.g. a POD. + + Runtime information of the set of OS + containers realizing an individual VNFC + instance is not part of the McioInfo data + structure; such runtime information is + provided in the ResourceHandle data structure + referenced from the VnfcResourceInfo. The + McioInfo does not provide runtime information + of a constituent VNFC instance created based + on a specific VDU. + + NOTE 1: The type of MCIO as specified in the + declarative descriptor of the MCIO, and that + can be read from + the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the + “kind” property of the declarative descriptor. + NOTE 2: If the attribute additionalInfo is + present, it may contain runtime information on + the actual and + desired state of the MCIO(s). + NOTE 3: When the container infrastructure + service is a Kubernetes® instance, the mcioId + is the combined + values from the kind and name fields of the Kubernetes resource object, separated by a slash. + Example: "Deployment/abcd". + NOTE 4: When the container infrastructure + service is a Kubernetes® instance, the + mcioName is the name + field of the resource object. + type: object + required: + - mcioId + - mcioName + - mcioNamespace + - vduId + - cismId + - mcioType + - desiredInstances + - availableInstances + properties: + mcioId: + description: > + An identifier with the intention of being + globally unique. + type: string + mcioName: + description: > + Human readable name of this MCIO. See note + 4. + type: string + mcioNamespace: + description: | + Namespace of this MCIO. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cismId: + description: > + An identifier with the intention of being + globally unique. + type: string + mcioType: + description: > + The type of MCIO. Specific values, their + semantics and associated MCIO types are + defined in clause 5.5.4.9. Additional + values are also permitted. See note 1. + type: string + enum: + - Deployment + - StatefulSet + - DaemonSet + desiredInstances: + description: | + Number of desired MCIO instances. + type: integer + availableInstances: + description: | + Number of available MCIO instances. + type: integer + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + certificateContentId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfPaasServiceInfo: + description: > + Information on the PaaS Services assigned and + used by the VNF instance. + type: array + items: + description: > + This type provides information about a PaaS + Service that is used by a VNF instance. The + PaasServiceInfo is comprised of various sets + of information. Some information comes from + the VNFD, other information comes from the + PaaS Service assets provided by the NFVO to + the VNFM, and other information is provided at + runtime information about the usage of the + PaaS Service. + type: object + required: + - id + - paasServiceId + - paasServiceType + - paasServiceRequestId + - paasServiceHandle + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being + globally unique. + type: string + paasServiceType: + description: > + The type of PaaS Service. The value of + this attribute is expected to be matched + against values of the registered PaaS + Services in the PSR. + type: string + paasServiceVersion: + description: | + A version. + type: string + paasServiceRequestId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + paasServiceHandle: + description: > + This type provides information enabling + the access and use of the PaaS Service by + the VNF instance. The type and format of + the handle depends on the form that the + PaaS Service is formed. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + indicators: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + instantiate: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + terminate: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scale: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scaleToLevel: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeFlavour: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + heal: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + operate: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeExtConn: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + createSnapshot: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + revertToSnapshot: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeCurrentVnfPkg: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperationLinks: + description: > + Links to the most recent LCM operation occurrences + related to this resource. See note 9. + type: object + properties: + recentVnfLcmOperation: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmInstantiation: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScale: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScaleToLevel: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeFlavour: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmTerminate: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmHeal: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperate: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeExtConn: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmModifyInfo: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmCreateSnapshot: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmRevertToSnapshot: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeVnfPkg: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmSelectDplMods: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfcSnapshots: + description: > + Information about VNFC snapshots constituting this VNF + snapshot. + type: array + items: + description: "This type represents a VNFC snapshot. * NOTE 1:\tThe identifier of the compute snapshot resource is assigned during creation of a VNFC\n snapshot being returned from the VIM as output data in the response message of the individual\n resource operations. This attribute shall only be present for a VNFC snapshot that has been\n newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n NOTE 2:\tThe identifier of the storage snapshot resource is assigned during creation of a VNFC snapshot\n being returned from the VIM as output data in the response message of the individual resource\n operations. This attribute shall only be present for a VNFC snapshot with an associated storage\n resource and that has been newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n" + type: object + required: + - id + - vnfcInstanceId + - creationStartedAt + - vnfcResourceInfoId + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfcInstanceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + creationStartedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + creationFinishedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + vnfcResourceInfoId: + description: "This type represents the information about a VNFC instance that is part of a VNF instance. * NOTE:\tThis allows to represent the error condition that a VNFC instance has lost its resources.\n" + type: object + required: + - id + - vduId + - vnfcState + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + vduId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + vnfcResourceInfoId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + vnfcState: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + vnfcConfigurableProperties: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + computeSnapshotResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + storageSnapshotResources: + description: > + Mapping of the storage resources associated to the + VNFC with the storage snapshot resources. + type: object + required: + - storageResourceId + properties: + storageResourceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + storageSnapshotResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. Information about + the resource is available from the VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource provider. + See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available from + the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be present + if the resource is managed by a CISM and + it shall be absent otherwise. + type: string + userDefinedData: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + userDefinedData: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + takenFrom: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualVnfSnapshot.Get.200: + description: > + 200 OK + + Shall be returned when information about an individual VNF snapshot was + read successfully. + + The response body shall contain a representation of the individual VNF + snapshot resource. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Link: + description: | + Reference to other resources. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: | + This type represents an individual VNF snapshot resource. + type: object + required: + - id + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfSnapshotPkgId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfSnapshot: + description: | + This type represents a VNF snapshot. + type: object + required: + - id + - vnfInstanceId + - triggeredAt + - vnfdId + - vnfInfo + - vnfcSnapshots + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + creationStartedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + creationFinishedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfInstance: + description: "This type represents a VNF instance. * NOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist\n between the previous and the newly referred VNF package, i.e. when the new VNFD is\n changed with respect to the previous VNFD in other aspects than merely referencing\n to other VNF software images. In order to avoid misalignment of the VnfInstance with\n the current VNF's on-boarded VNF package, the values of attributes in the VnfInstance\n that have corresponding attributes in the VNFD shall be kept in sync with the values in the VNFD.\n* NOTE 2:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 3:\tThese attributes are sometimes also referred to as configuration parameters\n applicable to a VNF. Some of these are set prior to instantiation and cannot be modified\n if the VNF is instantiated, some are set prior to instantiation (are part of initial configuration)\n and can be modified later, and others can be set only after instantiation.\n The applicability of certain configuration may depend on the VNF and the required operation of\n the VNF at a certain point in time.\n* NOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child\n attributes of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared\n in the VNFD with a defined initial value. The defined initial values can be declared in the VNFD,\n and/or, in case of \"metadata\", obtained from the \"CreateVnfRequest\" structure. Child attributes of\n \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that have no defined initial value shall\n not be created, in order to be consistent with the semantics of the JSON Merge Patch method\n (see IETF RFC 7396) that interprets null values as deletion request.\n* NOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case\n of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding\n to the same VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc\n and externally-managed multi-site VL instance (refer to clause 5.5.3.5).\n* NOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity,\n they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n* NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual extCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the VNF \n LCM operation explicitly indicates the scale level for the aspect.\n* NOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n" + type: object + required: + - id + - vnfdId + - vnfProvider + - vnfProductName + - vnfSoftwareVersion + - vnfdVersion + - instantiationState + - _links + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceName: + description: > + Name of the VNF instance. This attribute can be + modified with the PATCH method. + type: string + vnfInstanceDescription: + description: > + Human-readable description of the VNF instance. This + attribute can be modified with the PATCH method. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProvider: + description: > + Provider of the VNF and the VNFD. The value is copied + from the VNFD. + type: string + vnfProductName: + description: > + Name to identify the VNF Product. The value is copied + from the VNFD. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + certificateInfo: + description: > + This type provides input information related to + certificate and certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + certificateConfigurationInfo: + description: > + This type provides input information related to + certificate management. + type: object + required: + - securityPolicy + properties: + certificateBaseProfile: + description: > + This type provides input information to + override certificate base profile for + certificate management + + NOTE : At least one overriding attributes + shall be present, otherwise shall be absent. + required: + - id + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + issuer: + type: string + description: Issuer of certificates. See note. + issuerUniqueIdentifier: + description: > + An identifier with the intention of being + globally unique. + type: string + subject: + description: > + This type provides input information + related to subject of certificate. + + * NOTE: At least one overriding attributes + shall be present, otherwise shall be + absent. + type: object + properties: + commonName: + description: >- + Information of certification target + subject FQDN. See note. + type: string + organization: + description: >- + Information of certification target + subject Organization. See note. + type: string + country: + description: >- + Information of certification target + subject Country. See note. + type: string + state: + description: >- + Information of certification target + subject State. See note. + type: string + locality: + description: >- + Information of certification target + subject Locality. See note. + type: string + emailAddress: + description: >- + Information of certification contact + email address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of being + globally unique. + type: string + basicConstraints: + type: string + description: > + Basic constraints of certificates. See + note. + issuerAltName: + description: >- + Alternative name of issuer of certificates + in this NS. See note. + type: array + items: + type: string + subjectAltName: + description: >- + Alternative name of subject of + certificates. Shall be present when this + certificate is used for encrypted + communication using IP address and + subjectAltName attribute of + CertificateBaseProfile in CertificateDesc + of VNFD is empty (see ETSI GS NFV-IFA 011 + [7],clause 7.1.19.4). See note + type: array + items: + type: string + nameConstraints: + description: >- + Name constraints of certificates. See + note. + type: array + items: + type: string + securityPolicy: + description: > + Information for security policy to be + satisfied for certificate. + type: array + items: + description: > + This type provides input information related + to security policy for certificate + management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + maxValidityPeriod: + description: >- + Allowed max validity period for + certificates. + type: integer + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: integer + delegationSupportedCertificateManagements: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + cmfInfo: + description: > + This type provides input information related + to CMF for certificate management. + type: object + required: + - id + - endPoint + - supportedProtocol + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + endPoint: + description: End point of CMF instance. + type: object + required: + - ipAddress + - link + properties: + 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 + link: + description: > + This type represents a link to a + resource using an absolute URI. + type: object + required: + - href + properties: + href: + description: > + String formatted according to IETF RFC + 3986. + type: string + supportedProtocols: + description: Supported protocol by CMF instance. + type: array + items: + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + certificateChain: + description: Certificate chain that this CMF provides. + type: array + items: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + certificateContents: + description: > + Information for contents of issued certificates. + The information contained in this attribute may be + updated over time during the VNF LCM, e.g. + certificate(s) renewal. + type: array + items: + description: > + This type provides input information related to + certificate content. + type: object + required: + - id + - certificateDescId + - certificateType + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + certficateDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + certificateType: + description: Type of this certificate. + type: string + enum: + - VNFCI_CERT + - VNFOAM_CERT + supportedCertificateManagements: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + version: + description: | + A version. + type: string + serialNumber: + description: Serial number of this certificate. + type: integer + signatureAlgorithm: + description: Algorithm of this certificate's signature. + type: string + issuer: + description: Issuer of this certificate. + type: string + notBefore: + description: > + Date-time stamp. Representation: String + formatted according to IETF RFC 3339. + type: string + format: date-time + notAfter: + description: > + Date-time stamp. Representation: String + formatted according to IETF RFC 3339. + type: string + format: date-time + subject: + description: Subject of this certificate. + type: string + publicKeyAlgorithm: + description: Algorithm of this certificate's public key. + type: string + publicKey: + description: Public key of this certificate. + type: string + certificateExtensions: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + instantiationState: + description: | + The instantiation state of the VNF. + type: string + enum: + - NOT_INSTANTIATED + - INSTANTIATED + instantiatedVnfInfo: + description: > + Information specific to an instantiated VNF instance. + This attribute shall be present if the + instantiateState attribute value is INSTANTIATED. + type: object + required: + - flavourId + - vnfState + - extCpInfo + properties: + flavourId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfState: + description: > + STARTED: The VNF instance is up and running. + STOPPED: The VNF instance has been shut down. + type: string + enum: + - STARTED + - STOPPED + vnfPowerState: + description: > + This type represents information about the power + state of a VNF instance. + type: object + required: + - powerProfileId + - name + properties: + powerProfileId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + name: + description: > + Name of the power profile as provided in the + VNFD. + type: string + powerConsumptionInfo: + description: > + This type represents information about + estimated power consumption of the resources + associated with the power profile, as provided + in the VNFD. + type: object + required: + - minPowerConsumption + - maxPowerConsumption + - averagePowerConsumption + properties: + minPowerConsumption: + description: > + Minimum power consumption of this power + profile. Unit is KW/h. + type: integer + maxPowerConsumption: + description: > + Maximum power consumption of this power + profile. Unit is KW/h. + type: integer + averagePowerConsumption: + description: > + Average power consumption of this power + profile. Unit is KW/h. + type: integer + scaleStatus: + description: > + Scale status of the VNF, one entry per aspect. + Represents for every scaling aspect how "big" the + VNF has been scaled w.r.t. that aspect. This + attribute shall be present if the VNF supports + scaling. See clause B.2 for an explanation of VNF + scaling. For an aspect that has not been deployed + because the related deployableModule has not been + selected, it indicates the scale level that has + been requested in the instantiation or in a + scaling operation, or, if none has been requested + in any of them, the scale level applicable to the + aspect based on the default instantiation level. + See note 8. + type: array + items: + description: > + This type represents the scale level of a VNF + instance related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + scaleLevel: + description: > + Indicates the scale level. The minimum value + shall be 0 and the maximum value shall be <= + maxScaleLevel as described in the VNFD. + type: integer + maxScaleLevels: + description: > + Maximum allowed scale levels of the VNF, one entry + per aspect. This attribute shall be present if the + VNF supports scaling. + type: array + items: + description: > + This type represents the scale level of a VNF + instance related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + scaleLevel: + description: > + Indicates the scale level. The minimum value + shall be 0 and the maximum value shall be <= + maxScaleLevel as described in the VNFD. + type: integer + selectedDeployableModule: + description: > + References a currently selected deployable module, + as defined in the VNFD, that has already completed + the instantiation of its VNFCs + type: array + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + resourceCapacityDefinition: + description: > + Shows current values of VDU attributes related to + resource capacity, if different to the default + values from the VNFD, as indicated in the (one or + more) request(s) of all completed VNF LCM + operation(s) that contain this attribute. If an + attribute value has been modified multiple times, + only the last value is shown. The values + indicated in this attribute are applicable to all + VNFC instances based on the VDU to which the + resourceCapacityDefinition is related. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes. + + * NOTE: Resource definitions not related to a + VDU are not considered in this version of the + present document. + type: object + required: + - type + properties: + tag: + description: >- + Tag assigned by the issuer of a VNF LCM + operation request that contains this data + type with values to be applied to a VDU. It + is used for tracking purposes. The tag is + preserved in the run time record as long as + at least one value of the capacity related + attributes associated with that tag is still + valid, i.e., it has not been modified by a + later VNF LCM operation request. At most one + tag can be included when the data type is + used in a VNF LCM operation request. When + the data type is used in the VnfInstance + data type it may contain multiple tags, + namely those provided in VNF LCM requests, + if at least one of the values provided in + that request associated to that tag is still + applicable in the VNFCs created from this + VDU, i.e., it has not been modified by a + later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: "Type of the resource definition referenced. VALUES •\tCOMPUTE •\tSTORAGE •\tOSCONTAINER" + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + osContainerDescData: + description: >- + Indicates values for resource capacity + related attributes in an OsContainerDesc. It + shall be present when the attribute ‘type’ + indicates OSCONTAINER and absent otherwise. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes of an + OsContainer resource. + + * NOTE: At least one of the attributes + shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for + the container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for + the container expressed in the same + units as specified in the + requested_memory_resources_valid_values + property in VNFD for this container + descriptor. See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources + of the type indicated in the key. The + key is a string that identifies an + extended resource indicated in the + extended_resource_requests property in + the VNFD for this container descriptor. + The value is an integer that indicates + the required amount for a particular + extended resource.See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container + can maximally use in milli-CPU. See + note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required + for all the hugepages of the size + indicated in the key. The key is a + string and corresponds to one of the + values of the hugepage sizes indicated + in the huge_pages_resources property in + the VNFD for this container descriptor. + The value is a number that indicates the + required total size expressed in the + same units as in the + huge_pages_resources_property in the + VNFD that indicates the valid values for + required total size for the particular + hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power + state configuration data for the virtual + compute or OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU + cores are requested to be allocated to + logical CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states + of virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on + core utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for + capacity related VDU attributes of the + virtual compute resource of a VM. + + * NOTE: At least one of the attributes shall + be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - resourceTemplateId + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required + for all the hugepages of the size + indicated in the key. The key is a + string and corresponds to one of the + values of the hugepage sizes indicated + in the huge_pages_requirements property + in the VNFD for this virtual compute + descriptor. The value is a number that + indicates the required total size + expressed in the same units as in the + huge_pages_requirements property in the + VNFD that indicates the valid values for + required total size for the particular + hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power + state configuration data for the virtual + compute or OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU + cores are requested to be allocated to + logical CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states + of virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on + core utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size + related attribute in an VirtualStorageDesc. + It shall be present when the attribute + 'type' indicates STORAGE and absent + otherwise. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes of the + virtual storage resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + extCpInfo: + description: > + Information about the external CPs exposed by the + VNF instance. When trunking is enabled, the list + of entries includes both, external CPs + corresponding to parent ports of a trunk, and + external CPs associated to sub-ports of a trunk. + See note 7. + type: array + minItems: 1 + items: + description: "This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n" + type: object + required: + - id + - cpdId + - cpConfigId + - cpProtocolInfo + oneOf: + - required: + - associatedVnfcCpId + - required: + - associatedVipCpId + - required: + - associatedVnfVirtualLinkId + properties: + id: + 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 + cpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolInfo: + description: | + Network protocol information for this CP. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + extLinkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + associatedVnfcCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVipCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVirtualCpId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + associatedVnfVirtualLinkId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceInfo” + structure that provides the specification of + the interface to attach the connection point + to a secondary container cluster network. + See notes 3 and 4. It shall be present if + the external CP is associated to a VNFC + realized by one or a set of OS containers + and is connected to a secondary container + cluster network. It shall not be present + otherwise. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + certificateContentId: + description: > + An identifier with the intention of being + globally unique. + type: string + cpSecurityGroupInfo: + description: > + This type provides the list of active + security group rules applied to an external + CP instance. The type identifies which + "SecurityGroupRule" specified in the VNFD + are activated and the values of its + attributes. + type: object + required: + - securityGroupRuleId + - etherType + - protocol + - portRangeMin + - portRangeMax + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + description: + description: > + Human readable description of the + security group rule. + type: string + etherType: + description: > + Indicates the protocol carried over the + Ethernet layer. Permitted values: IPV4, + IPV6. + type: string + enum: + - IPV4 + - IPV6 + protocol: + description: > + Indicates the protocol carried over the + IP layer. Permitted values: any protocol + defined in the IANA protocol registry + (refer to clause 9.10.1.2 ofd ETSI GS + NFV-SOL 001 for further information). + type: string + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. + type: integer + vipCpInfo: + description: > + VIP CPs that are part of the VNF instance. Shall + be present when that particular VIP CP of the VNFC + instance is associated to an external CP of the + VNF instance. + + May be present otherwise. + type: array + items: + description: "This type provides information related to virtual IP CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n" + type: object + required: + - cpInstanceId + - cpdId + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There + shall be one cpProtocolInfo for layer 3. + There may be one cpProtocolInfo for layer 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + associatedVnfcCpIds: + description: > + Identifiers of the VnfcCps that share the + virtual IP address allocated to the VIP CP + instance. See note. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + virtualCpInfo: + description: > + Virtual CPs that are part of the VNF instance. + Shall be present when a particular virtual CP is + associated to an external CP of the VNF instance. + May be present otherwise. + type: array + items: + description: > + This type provides information related to a + virtual CP instance of a VNF. + + * NOTE 1: A consumer of the VNF LCM interface + can learn the actual VNFC instances implementing + the service + accessible via the virtual CP instance by querying the "vnfcResourceInfo" from the "InstantiatedVnfInfo" + and filtering by corresponding "vduIds" values. + * NOTE 2: The information can be omitted because + it is already available as part of the external + CP information in the + VnfExtCpInfo structure. + type: object + required: + - cpInstanceId + - cpdId + - resourceHandle + - vduIds + properties: + cpInstanceId: + 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 + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There + shall be one cpProtocolInfo for each layer + protocol supported. This attribute may be + omitted if the virtual CP is exposed as an + external CP. See note 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vduIds: + description: > + Reference to the VDU(s) which implement the + service accessible via the virtual CP + instance. See note. + type: array + minItems: 1 + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + additionalServiceInfo: + description: > + Additional service identification + information of the virtual CP instance. + type: array + items: + description: > + This type provides additional service + information of the virtual CP instance + used to expose properties of the virtual + CP to NFV-MANO. + + NOTE: This attribute shall only be present + if additional information is needed to + identify the service + termination within the VNF, such as for example a URL path information in an HTTP request required + to allow a single virtual CP IP address to be used for several HTTP based services that use the + same port number. + type: object + required: + - portInfo + properties: + portInfo: + description: > + Service port numbers exposed by the + virtual CP instance. + minItems: 1 + type: array + items: + description: > + This type describes the service + identifying port properties exposed by + the virtual CP instance. + type: object + required: + - name + - port + - portConfigurable + properties: + name: + description: > + The name of the port exposed by the + virtual CP instance. + type: string + protocol: + description: > + The L4 protocol for this port exposed by + the virtual CP instance. + + Permitted values: - TCP - UDP - SCTP + type: string + enum: + - TCP + - UDP + - SCTP + port: + description: > + The L4 port number exposed by the + virtual CP instance. + type: integer + portConfigurable: + description: > + The Boolean is a data type having two + values (true and false). + type: boolean + serviceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + extVirtualLinkInfo: + description: > + Information about the external VLs the VNF + instance is connected to. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM + or CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the current + CP configuration information for the + connection of external CPs to the external + virtual link. See note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be + configured on the CP instances created + from the respective CPD. The key of the + map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the + NFVO. The entries shall be applied by + the VNFM according to the rules of JSON + Merge Patch (see IETF RFC 7396). See + notes 2, 3, 4, 5 and 6. In case of + deleting an external CP, the list of + instances to be deleted. + type: object + additionalProperties: + description: > + This type represents an externally + provided link port, or a network + attachment definition resource of + secondary container cluster network, or + network address information per instance + of an external connection point. In the + case of VM-based deployment of the VNFC + exposing the external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based + deployment of the VNFC exposing the + external CP, the VNFM shall use the + network attachment definition resource + of secondary container cluster network + when connecting the CP to the external + VL. + + * NOTE 1: The following conditions apply + to the attributes "linkPortId" and + "cpProtocolData" for an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply + to the attributes “netAttDefResourceId” + and “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is + only applicable for specific cases where + more than one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but + not both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of + being globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create + a dedicated link port for the external + CP. If set to True, the VNFM shall + create a link port. If set to False, the + VNFM shall not create a link port. This + attribute is only applicable for + external CP instances without a floating + IP address that expose a VIP CP instance + for which a dedicated IP address is + allocated. It shall be present in that + case and shall be absent otherwise. + type: boolean + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects + the CP to a VL and the domain names for + the external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the + CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored. + + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security + groups. The parameters identify which + "SecurityGroupRule" specified in the + VNFD is activated/deactivated and for an + activated security group rule the values + of attributes defined in the VNFD that + can be overriden such as "portRangeMin" + and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceData” structure that + provides the specification of the + interface to attach the external CP to a + secondary container cluster network. It + is only applicable if the external CP is + connected or to be connected to a + secondary container cluster network. It + shall not be present if the external CP + is related to a virtual network not + categorized as secondary container + cluster network. See notes 2, 3 and 4. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + extNetAttDefResource: + description: > + Network attachment definition resources that + provide the specification of the interface + to attach connection points to this VL. + type: array + items: + description: > + This type contains information related to + a network attachment definition resource + that provides the specification of the + interface used to connect one or multiple + connection points to a secondary + container cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of + being globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM + or CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated + to this network attachment definition + resource. Shall be present when the + network attachment definition resource + is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to + this network attachment definition + resource. May be present when the + network attachment definition resource + is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + routingResource: + description: > + Network resources that provide the + forwarding/routing capabilities associated + to the network resource realizing this VL. + type: array + items: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be populated + in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + extManagedVirtualLinkInfo: + description: > + Information about the externally managed internal + VLs of the VNF instance. See note 5 and note 6. It + is possible to have several + ExtManagedVirtualLinkInfo for the same VNF + internal VL in case of a multi-site VNF spanning + several VIMs. The set of ExtManagedVirtualLinkInfo + corresponding to the same VNF internal VL shall + indicate so by referencing to the same + VnfVirtualLinkDesc and externally-managed + multi-site VL instance (refer to clause 5.5.3.5). + Even though externally-managed internal VLs are + also used for VNF-internal connectivity, they + shall not be listed in the + "vnfVirtualLinkResourceInfo" attribute as this + would be redundant. + type: array + items: + description: > + This type provides information about an + externally-managed virtual link. *NOTE: Both + vnfLinkPort and vnfNetAttDefResource can be + present in an ExtManagedVirtualLinkInfo to + indicate that + a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + vnfLinkPorts: + description: | + Link ports of this VL.See note. + type: array + items: + description: > + This type represents a link port of an + internal VL of a VNF. + + NOTE 1: Either cpInstanceId with + cpInstanceType set to "EXT_CP" or any + combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 + provides examples for configurations where + both vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is + scoped by the value of "vimConnectionId" + in the "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM + or CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vnfNetAttDefResource: + description: > + Network attachment definition resources that + provide the specification of the interface + to attach connection points to this VL. + type: array + items: + description: > + This type contains information related to + a network attachment definition resource + that provides the specification of the + interface used to connect one or multiple + connection points to a secondary + container cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of + being globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM + or CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated + to this network attachment definition + resource. Shall be present when the + network attachment definition resource + is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to + this network attachment definition + resource. May be present when the + network attachment definition resource + is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + routingResource: + description: > + Network resources that provide the + forwarding/routing capabilities associated + to the network resource realizing this VL. + type: array + items: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be populated + in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + monitoringParameters: + description: | + Active monitoring parameters. + type: array + items: + type: object + required: + - id + - performanceMetric + properties: + id: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + name: + description: > + Human readable name of the monitoring + parameter, as defined in the VNFD. + type: string + performanceMetric: + description: > + Performance metric that is monitored. This + attribute shall contain the related + "Measurement Name" value as defined in + clause 7.2 of ETSI GS NFV-IFA 027. + type: string + localizationLanguage: + description: > + Information about localization language of the VNF + (includes e.g. strings in the VNFD). The + localization languages supported by a VNF can be + declared in the VNFD, and localization language + selection can take place at instantiation time. + The value shall comply with the format defined in + IETF RFC 5646. + type: string + vnfcResourceInfo: + description: > + Information about the virtualised compute and + storage resources used by the VNFCs of the VNF + instance. + type: array + items: + description: "This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure \n of information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n - For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n - For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\n\n* NOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. * NOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an internal VL that\n exposes an external CP. A VNFC CP is \"exposed as\" an external CP if it is connected directly\n to an external VL.\n* NOTE 3:\tThe information can be omitted because it is already available as part of the external CP information. * NOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\" structure by \n an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVnfc\"\n structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to \n this LCM operation occurrence.\n* NOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment \n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build \n a link redundant mated pair in SR-IOV cases.\n* NOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. * NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n" + type: object + required: + - id + - vduId + - computeResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + storageResourceIds: + description: > + References to the VirtualStorage resources + or references to Storage MCIO(s). The value + refers to a VirtualStorageResourceInfo item + in the VnfInstance. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfcCpInfo: + description: > + All the CPs of the VNFC instance. See note + 7. + type: array + items: + type: object + required: + - id + - cpdId + properties: + id: + 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 + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpProtocolInfo: + description: > + Network protocol information for this + CP. May be omitted if the VNFC CP is + exposed as an external CP. The + information can be omitted because it is + already available as part of the + external CP information. See note 3. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI’s transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + parentCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceInfo” structure that + provides the specification of the + interface to attach the connection + point to a secondary container cluster + network. See notes 5 and 6. It shall be + present if the internal CP is associated + to a VNFC realized by one or a set of + OS containers and is connected to a + secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + certificateContentId: + description: > + Identifier(s) of the + "CertificateContent" structure that + provides the information of the + certificate(s) that this VNFC CP + instance uses. Shall be present when + using in delegation-mode. Otherwise + shall not be present. This attribute + shall be supported when delegation mode + in certificate management is applicable. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this VNFC CP + instance uses. Shall be present when using + in delegation-mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfVirtualLinkResourceInfo: + description: > + Information about the virtualised network + resources used by the VLs of the VNF instance. See + note 6. Even though externally-managed internal + VLs are also used for VNF-internal connectivity, + they shall not be listed in the + "vnfVirtualLinkResourceInfo" attribute as this + would be redundant. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used + by an internal VL instance in a VNF instance. + NOTE: If only the value or the presence of this + attribute is changed in the + "VnfVirtualLinkResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires including a + related "AffectedVirtualLink" structure in the VNF LCM operation occurrence notifications or the + "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + - vnfLinkPorts + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfLinkPorts: + description: > + Links ports of this VL. Shall be present + when the linkPort is used for external + connectivity by the VNF (refer to + VnfLinkPortInfo). May be present otherwise. + type: array + items: + description: > + This type represents a link port of an + internal VL of a VNF. + + NOTE 1: Either cpInstanceId with + cpInstanceType set to "EXT_CP" or any + combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 + provides examples for configurations where + both vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is + scoped by the value of "vimConnectionId" + in the "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM + or CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container + infrastructure service is a Kubernetes® + instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + virtualStorageResourceInfo: + description: > + Information on the virtualised storage resource(s) + used as storage for the VNF instance. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used + by a VNF instance. + + NOTE: If only the value or the presence of this + attribute is changed in the + "VirtualStorageResourceInfo" structure by an LCM + operation occurrence, this does not represent a + change that requires including a related + "AffectedVirtualStorage" structure in the VNF + LCM operation occurrence notifications or the + "VnfLcmOpOcc" structure related to this LCM + operation occurrence. + type: object + required: + - id + - virtualStorageDescId + - storageResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The information about the VIM or + CISM connection referenced by the VIM + connection id is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the + resourceId shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + vnfcInfo: + description: | + Information about the VNFC instances. + type: array + items: + description: "This type represents the information about a VNFC instance that is part of a VNF instance. * NOTE:\tThis allows to represent the error condition that a VNFC instance has lost its resources.\n" + type: object + required: + - id + - vduId + - vnfcState + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vduId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfcResourceInfoId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfcState: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfcConfigurableProperties: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + mcioInfo: + description: > + Information on the MCIO(s) representing VNFC + instance(s) realized by one or a set of OS + containers and created from the same VDU for the + VNF instance. + type: array + items: + description: > + This type provides information about an MCIO + representing the set of VNFC instances realized + by one or a set of OS containers which have + been created based on the same VDU. Within the + CISM, an MCIO controller monitors the actual + state of an MCIO representing the set of VNFC + instances realized by one or a set of OS + containers and compare it to the desired state. + For an MCIO related to a VDU that has the + attribute "isNumOfInstancesClusterBased" set to + FALSE the desired state is specified in the + respective declarative descriptor. For an MCIO + related to a VDU that has the attribute + "isNumOfInstancesClusterBased" set to TRUE, the + desired state is determined by the number of + CIS-nodes in the cluster that fulfil the VDU + requirements. It triggers actions toward the CIS + to align the actual to the desired state. + Monitoring the actual state includes monitoring + the number of MCIO instances available at any + specific point in time. In addition, an MCIO + controller maintains properties and runtime + information on the MCIO instances which have + been created based on the same VDU. The McioInfo + data structure provides the runtime information + on the MCIOs obtained from the MCIO controller. + + NOTE: There are different types of MCIOs. The + set of VNFC instances based on the same VDU is + represented + by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type + of MCIO, e.g. a POD. + + Runtime information of the set of OS containers + realizing an individual VNFC instance is not + part of the McioInfo data structure; such + runtime information is provided in the + ResourceHandle data structure referenced from + the VnfcResourceInfo. The McioInfo does not + provide runtime information of a constituent + VNFC instance created based on a specific VDU. + + NOTE 1: The type of MCIO as specified in the + declarative descriptor of the MCIO, and that can + be read from + the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the + “kind” property of the declarative descriptor. + NOTE 2: If the attribute additionalInfo is + present, it may contain runtime information on + the actual and + desired state of the MCIO(s). + NOTE 3: When the container infrastructure + service is a Kubernetes® instance, the mcioId is + the combined + values from the kind and name fields of the Kubernetes resource object, separated by a slash. + Example: "Deployment/abcd". + NOTE 4: When the container infrastructure + service is a Kubernetes® instance, the mcioName + is the name + field of the resource object. + type: object + required: + - mcioId + - mcioName + - mcioNamespace + - vduId + - cismId + - mcioType + - desiredInstances + - availableInstances + properties: + mcioId: + description: > + An identifier with the intention of being + globally unique. + type: string + mcioName: + description: > + Human readable name of this MCIO. See note + 4. + type: string + mcioNamespace: + description: | + Namespace of this MCIO. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cismId: + description: > + An identifier with the intention of being + globally unique. + type: string + mcioType: + description: > + The type of MCIO. Specific values, their + semantics and associated MCIO types are + defined in clause 5.5.4.9. Additional + values are also permitted. See note 1. + type: string + enum: + - Deployment + - StatefulSet + - DaemonSet + desiredInstances: + description: | + Number of desired MCIO instances. + type: integer + availableInstances: + description: | + Number of available MCIO instances. + type: integer + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + certificateContentId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfPaasServiceInfo: + description: > + Information on the PaaS Services assigned and used + by the VNF instance. + type: array + items: + description: > + This type provides information about a PaaS + Service that is used by a VNF instance. The + PaasServiceInfo is comprised of various sets of + information. Some information comes from the + VNFD, other information comes from the PaaS + Service assets provided by the NFVO to the VNFM, + and other information is provided at runtime + information about the usage of the PaaS Service. + type: object + required: + - id + - paasServiceId + - paasServiceType + - paasServiceRequestId + - paasServiceHandle + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being + globally unique. + type: string + paasServiceType: + description: > + The type of PaaS Service. The value of this + attribute is expected to be matched against + values of the registered PaaS Services in + the PSR. + type: string + paasServiceVersion: + description: | + A version. + type: string + paasServiceRequestId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + paasServiceHandle: + description: > + This type provides information enabling the + access and use of the PaaS Service by the + VNF instance. The type and format of the + handle depends on the form that the PaaS + Service is formed. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + indicators: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + instantiate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + terminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + heal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + operate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + createSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + revertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeCurrentVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperationLinks: + description: > + Links to the most recent LCM operation occurrences + related to this resource. See note 9. + type: object + properties: + recentVnfLcmOperation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmInstantiation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmTerminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmHeal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmModifyInfo: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmCreateSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmRevertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmSelectDplMods: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfcSnapshots: + description: > + Information about VNFC snapshots constituting this VNF + snapshot. + type: array + items: + description: "This type represents a VNFC snapshot. * NOTE 1:\tThe identifier of the compute snapshot resource is assigned during creation of a VNFC\n snapshot being returned from the VIM as output data in the response message of the individual\n resource operations. This attribute shall only be present for a VNFC snapshot that has been\n newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n NOTE 2:\tThe identifier of the storage snapshot resource is assigned during creation of a VNFC snapshot\n being returned from the VIM as output data in the response message of the individual resource\n operations. This attribute shall only be present for a VNFC snapshot with an associated storage\n resource and that has been newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n" + type: object + required: + - id + - vnfcInstanceId + - creationStartedAt + - vnfcResourceInfoId + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfcInstanceId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + creationStartedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + creationFinishedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + vnfcResourceInfoId: + description: "This type represents the information about a VNFC instance that is part of a VNF instance. * NOTE:\tThis allows to represent the error condition that a VNFC instance has lost its resources.\n" + type: object + required: + - id + - vduId + - vnfcState + properties: + id: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vduId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfcResourceInfoId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfcState: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfcConfigurableProperties: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + computeSnapshotResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service + is a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + storageSnapshotResources: + description: > + Mapping of the storage resources associated to the + VNFC with the storage snapshot resources. + type: object + required: + - storageResourceId + properties: + storageResourceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + storageSnapshotResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used + by a VNF instance. Information about the + resource is available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id + is known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See + note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the + VIM or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall + be absent otherwise. + type: string + userDefinedData: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + userDefinedData: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + takenFrom: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualVnfSnapshot.Delete.204: + description: > + 204 NO CONTENT + + The "Individual subscription" resource has been deleted successfully. + The response body shall be empty. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + content: {} + IndividualVnfSnapshot.Delete.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that the VNF + instance resource is in NOT_INSTANTIATED + state, or that another lifecycle management + operation is ongoing. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall + convey more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + Selectdeployablemodules.Post.202: + description: > + 202 ACCEPTED + + + Shall be returned when the request has been accepted for processing. + + The response body shall be empty. + + The HTTP response shall include a "Location" HTTP header that contains + the URI of the newly-created + + "Individual VNF LCM operation occurrence" resource corresponding to the + operation. + headers: + Location: + description: | + The resource URI of the created "Individual VNF LCM operation + occurrence" resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + diff --git a/v5.3.1/SOL002-VNFLifecycleManagementNotification-API.json b/v5.3.1/SOL002-VNFLifecycleManagementNotification-API.json new file mode 100644 index 00000000..af221b45 --- /dev/null +++ b/v5.3.1/SOL002-VNFLifecycleManagementNotification-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL002 - VNF Lifecycle Management Notification interface","description":"SOL002 - VNF Lifecycle Management Notification interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"2.16.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 002 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/05.03.01_60/gs_NFV-SOL002v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/callback/v2"},{"url":"https://127.0.0.1/callback/v2"}],"paths":{"/URI_is_provided_by_the_client_when_creating_the_subscription-VnfLcmOperationOccurrenceNotification":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method allows the server to test the notification endpoint that is provided by the API consumer,\ne.g. during subscription. See clause 5.4.20.3.2.\n","responses":{"204":{"$ref":"#/components/responses/VNFLCMNotification.Get.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"The POST method delivers a notification from the API producer to an API consumer. The API consumer shall have\npreviously created an \"Individual subscription\" resource with a matching filter. See clause 5.4.20.3.1.\n","parameters":[{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/VnfLcmOperationOccurrenceNotification"},"responses":{"204":{"$ref":"#/components/responses/VNFLCMNotification.Post.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/URI_is_provided_by_the_client_when_creating_the_subscription-VnfIdentifierCreationNotification":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method allows the server to test the notification endpoint that is provided by the API consumer,\ne.g. during subscription. See clause 5.4.20.3.2.\n","responses":{"204":{"$ref":"#/components/responses/VNFLCMNotification.Get.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"The POST method delivers a notification from the API producer to an API consumer. The API consumer shall have\npreviously created an \"Individual subscription\" resource with a matching filter. See clause 5.4.20.3.1.\n","parameters":[{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/VnfIdentifierCreationNotification"},"responses":{"204":{"$ref":"#/components/responses/VNFLCMNotification.Post.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/URI_is_provided_by_the_client_when_creating_the_subscription-VnfIdentifierDeletionNotification":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method allows the server to test the notification endpoint that is provided by the API consumer,\ne.g. during subscription. See clause 5.4.20.3.2.\n","responses":{"204":{"$ref":"#/components/responses/VNFLCMNotification.Get.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"The POST method delivers a notification from the API producer to an API consumer. The API consumer shall have\npreviously created an \"Individual subscription\" resource with a matching filter. See clause 5.4.20.3.1.\n","parameters":[{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/VnfIdentifierDeletionNotification"},"responses":{"204":{"$ref":"#/components/responses/VNFLCMNotification.Post.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"requestBodies":{"VnfLcmOperationOccurrenceNotification":{"description":"A notification about lifecycle changes triggered by a VNF LCM operation occurrence.\n","content":{"application/json":{"schema":{"description":"This type represents a VNF lifecycle management operation occurrence notification, which informs the receiver of changes in the VNF lifecycle caused by a VNF LCM operation occurrence. The support of the notification is mandatory. This notification shall be triggered by the VNFM when there is a change in the VNF lifecycle caused by a VNF LCM operation occurrence, including: * Instantiation of the VNF * Scaling of the VNF instance (including auto-scaling) * Healing of the VNF instance (including auto-healing) * Change of the state of the VNF instance (i.e. Operate VNF) * Change of the deployment flavour of the VNF instance * Change of the external connectivity of the VNF instance * Selection of deployable modules of the VNF instance * Termination of the VNF instance * Modification of VNF instance information and/or VNF configurable\n properties through the \"PATCH\" method on the \"Individual VNF instance\"\n resource.\nIf this is the initial notification about the start of a VNF LCM operation occurrence, it is assumed that the notification is sent by the VNFM before any action (including sending the grant request) is taken as part of the LCM operation. Due to possible race conditions, the \"start\" notification, the grant request and the LCM operation acknowledgment can arrive in any order at the NFVO, and the NFVO shall be able to handle such a situation. If this is a notification about a final or intermediate result state of a VNF LCM operation occurrence, the notification shall be sent after all related actions of the LCM operation that led to this state have been executed. The new state shall be set in the \"Individual VNF LCM operation occurrence\" resource before the notification about the state change is sent. * NOTE 1:\tShall be present if the \"notificationStatus\" is set to \"RESULT\", the \"verbosity\" attribute is set\n to \"FULL\" and the operation has performed any resource modification. Shall be absent otherwise.\n This attribute contains information about the cumulative changes to virtualised resources that\n were performed so far by the VNF LCM operation occurrence and by any of the error handling\n procedures for that operation occurrence.\n NOTE 2:\tFor a particular affected VL, there shall be as many \"AffectedVirtualLink\" entries as needed\n for signalling the different types of changes, i.e. one per virtual link and change type.\n For instance, in the case of signaling affected VL instances involving the addition of a particular\n VL instance with links ports, one \"AffectedVirtualLink\" entry signals the addition of the VL by using\n the \"changeType\" attribute of \"AffectedVirtualLink\" structure equal to \"ADDED\", and another\n \"AffectedVirtualLink\" entry signals the addition of VNF link ports of the VL by using the\n \"changeType\" equal to \"LINK_PORT_ADDED\".\n NOTE 3: Not more than one of changedInfo and modificationsTriggeredByVnfPkgChange shall be present.\n","type":"object","required":["id","notificationType","subscriptionId","timeStamp","notificationStatus","operationState","vnfInstanceId","operation","isAutomaticInvocation","vnfLcmOpOccId","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"VnfLcmOperationOccurrenceNotification\" for this notification type.\n","type":"string","enum":["VnfLcmOperationOccurrenceNotification"]},"subscriptionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"notificationStatus":{"description":"Indicates whether this notification reports about the start of a lifecycle operation or the result of a lifecycle operation. Permitted values: * START: Informs about the start of the VNF LCM operation occurrence.\n* RESULT: Informs about the final or intermediate result of the VNF LCM operation occurrence.\n","type":"string","enum":["START","RESULT"]},"operationState":{"description":"STARTING: The LCM operation is starting. PROCESSING: The LCM operation is currently in execution. COMPLETED: The LCM operation has been completed successfully. FAILED_TEMP: The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED: The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK: The LCM operation is currently being rolled back. ROLLED_BACK: The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible.\n","type":"string","enum":["STARTING","PROCESSING","COMPLETED","FAILED_TEMP","FAILED","ROLLING_BACK","ROLLED_BACK"]},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"operation":{"description":"The enumeration LcmOpType defines the permitted values to represent VNF lifecycle operation types in VNF lifecycle management operation occurrence resources and VNF lifecycle management operation occurrence notifications.\nValue | Description ------|------------ INSTANTIATE | Represents the \"Instantiate VNF\" LCM operation. SCALE | Represents the \"Scale VNF\" LCM operation. SCALE_TO_LEVEL | Represents the \"Scale VNF to Level\" LCM operation. CHANGE_FLAVOUR | Represents the \"Change VNF Flavour\" LCM operation. TERMINATE | Represents the \"Terminate VNF\" LCM operation. HEAL | Represents the \"Heal VNF\" LCM operation. OPERATE | Represents the \"Operate VNF\" LCM operation. CHANGE_EXT_CONN | Represents the \"Change external VNF connectivity\" LCM operation. MODIFY_INFO | Represents the \"Modify VNF Information\" LCM operation. CREATE_SNAPSHOT | Represents the \"Create VNF Snapshot\" LCM operation. REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot\" LCM operation. CHANGE_VNFPKG | Represents the \"Change current VNF package\" LCM operation. SELECT_DEPL_MODS | Represents the \"Select VNF deployable modules\" LCM operation\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","MODIFY_INFO","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","CHANGE_VNFPKG","SELECT_DEPL_MODS"]},"isAutomaticInvocation":{"description":"Set to true if this VNF LCM operation occurrence has been triggered by an automated procedure inside the VNFM (i.e. ScaleVnf / ScaleVnfToLevel triggered by auto-scale, or HealVnf triggered by auto-heal). Set to false otherwise.\n","type":"boolean"},"verbosity":{"description":"The enumeration LcmOpOccNotificationVerbosityType provides values to control the verbosity of LCM operation occurrence notifications. * FULL: This signals a full notification which contains all change details. * SHORT: This signals a short notification which omits large-volume change details to reduce the size of data to be sent via the notification mechanism.\n","type":"string","enum":["FULL","SHORT"]},"vnfLcmOpOccId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"affectedVnfcs":{"description":"Information about VNFC instances that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary VNFCs.\n","type":"object","required":["id","vduId","changeType","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY For a temporary resource, an AffectedVnfc structure exists as long as the temporary resource exists.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY"]},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"affectedVnfcCpIds":{"description":"Identifiers of CP(s) of the VNFC instance that were affected by the change. Shall be present for those affected CPs of the VNFC instance that are associated to an external CP of the VNF instance. May be present for further affected CPs of the VNFC instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"addedStorageResourceIds":{"description":"References to VirtualStorage resources that have been added. Each value refers to a VirtualStorageResourceInfo item in the VnfInstance that was added to the VNFC. It shall be provided if at least one storage resource was added to the VNFC.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"removedStorageResourceIds":{"description":"References to VirtualStorage resources that have been removed. The value contains the identifier of a VirtualStorageResourceInfo item that has been removed from the VNFC, and might no longer exist in the VnfInstance. It shall be provided if at least one storage resource was removed from the VNFC.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"affectedVirtualLinks":{"description":"Information about VL instances that were affected during the lifecycle operation. See note 1 and note 2.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary VLs, and added or removed VNF link ports.\nNOTE:\tWhen signalling the addition (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) of VNF link ports, \n the \"networkResource\" attribute refers to the affected virtual link instance, not the link port \n instance. The resource handles of the affected VNF link ports can be found by dereferencing the \n identifiers in the \"vnfLinkPortIds\" attribute.\n","type":"object","required":["id","vnfVirtualLinkDescId","changeType","networkResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY * LINK_PORT_ADDED * LINK_PORT_REMOVED For a temporary resource, an AffectedVirtualLink structure exists as long as the temporary resource exists. When signalling the addition (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) of VNF link ports, the \"networkResource\" attribute refers to the affected virtual link instance, not the link port instance. The resource handles of the affected VNF link ports can be found by dereferencing the identifiers in the \"vnfLinkPortIds\" attribute.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY","LINK_PORT_ADDED","LINK_PORT_REMOVED"]},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPortIds":{"description":"Identifiers of the link ports of the affected VL related to the change. Each identifier references a \"VnfLinkPortInfo\" structure.\nShall be set when changeType is equal to \"LINK_PORT_ADDED\" or \"LINK_PORT_REMOVED\", and the related \"VnfLinkPortInfo\" structures are present (case \"added\") or have been present (case \"removed\") in the \"VnfVirtualLinkResourceInfo\" or \"ExtManagedVirtualLinkInfo\" structures that are represented by the \"vnfVirtualLinkResourceInfo\" or \"extManagedVirtualLinkInfo\" attribute in the \"VnfInstance\" structure. See note.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"affectedExtLinkPorts":{"description":"Information about external VNF link ports that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added and deleted external link ports (link ports attached to external virtual links).\n","type":"object","required":["id","changeType","extCpInstanceId","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: -\tADDED - MODIFIED -\tREMOVED\n","type":"string","enum":["ADDED","MODIFIED","REMOVED"]},"extCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"affectedVirtualStorages":{"description":"Information about virtualised storage instances that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary virtual storage resources.\n","type":"object","required":["id","virtualStorageDescId","changeType","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY For a temporary resource, an AffectedVirtualStorage structure exists as long as the temporary resource exists.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY"]},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"changedInfo":{"description":"This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource. The attributes that can be included consist of those requested to be modified explicitly in the \"VnfInfoModificationRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly e.g. when modifying the referenced VNF package. * NOTE:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute)\n was modified implicitly following a request to modify the \"vnfdId\" attribute, by\n copying the value of this attribute from the VNFD in the VNF Package identified\n by the \"vnfdId\" attribute.\n","type":"object","properties":{"vnfInstanceName":{"description":"If present, this attribute signals modifications of the \"vnfInstanceName\" attribute in \"VnfInstance\" as defined in clause 5.5.2.12..\n","type":"string"},"vnfInstanceDescription":{"description":"If present, this attribute signals modifications of the \"vnfInstanceDescription\" attribute in \"VnfInstance\", as defined in clause 5.5.2.12..\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"If present, this attribute signals modifications of the \"vnfProvider\" attribute in \"VnfInstance\". See note.\n","type":"string"},"vnfProductName":{"description":"If present, this attribute signals modifications of the \"vnfProductName\" attribute in \"VnfInstance\". See note.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vnfcInfoModifications":{"description":"If present, this attribute signals modifications of certain entries in the \"vnfcInfo\" attribute array in the \"instantiatedVnfInfo\" attribute of \"VnfInstance\", as defined in clause 5.5.2.12.\n","type":"array","items":{"description":"This type represents modifications of an entry in an array of \"VnfcInfo\" objects. * NOTE:\tThe attribute \"id\" in this data type represents the same identifier as the attribute\n \"vnfcInstanceId\" in other related data types in the present document. For reasons of backward\n compatibility, this misalignment is not corrected.\n","type":"object","required":["id","vnfcConfigurableProperties"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfcConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"affectedVipCps":{"description":"Information about virtual IP CP instances that were affected during the execution of the lifecycle management operation, if this notification represents the result of a lifecycle management operation occurrence. Shall be present if the \"notificationStatus\" is set to \"RESULT\", the \"verbosity\" attribute is set to \"FULL\" and the operation has made any changes to the VIP CP instances of the VNF instance. Shall be absent otherwise. Only information about VIP CP instances that have been added, deleted or modified shall be provided.\n","type":"array","items":{"description":"This type provides information about added, deleted and modified virtual IP CP instances.\n","type":"object","required":["cpInstanceId","cpdId","changeType"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: -\tADDED -\tREMOVED -\tMODIFIED\n","type":"string","enum":["ADDED","REMOVED","MODIFIED"]}}}},"affectedVirtualCps":{"description":"Information about virtual CP instances that were affected during the execution of the lifecycle management operation, if this notification represents the result of a lifecycle management operation occurrence.\nShall be present if the \"notificationStatus\" is set to \"RESULT\", the \"verbosity\" attribute is set to \"FULL\" and the operation has made any changes to the virtual CP instances of the VNF instance. Shall be absent otherwise. Only information about virtual CP instances that have been added, deleted or modified shall be provided.\n","type":"array","items":{"description":"This type provides information about added, deleted and modified virtual CP instances.\n","type":"object","required":["cpInstanceId","cpdId","changeType"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change.\nPermitted values:\n - ADDED\n - REMOVED\n - MODIFIED\n","type":"string","enum":["ADDED","REMOVED","MODIFIED"]}}}},"affectedCertificates":{"description":"Information about certificate content that were affected during the execution of the lifecycle management operation, if this notification represents the result of a lifecycle management operation occurrence. Shall be present when using delegation mode, otherwise shall be absent. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"This type provides input information about added, deleted and modified certificate contents.\n","type":"object","required":["certificateInfoId","changeType"],"properties":{"certificateInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateBaseProfileId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"securityPolicyId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cmfInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateContentId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change.\n","type":"string","enum":["ADD","REMOVE","MODIFY"]}}}},"changedExtConnectivity":{"description":"Information about changed external connectivity, if this notification represents the result of a lifecycle operation occurrence. Shall be present if the \"notificationStatus\" is set to \"RESULT\" and the \"operation\" has made any change of the external connectivity of the VNF instance. Shall be absent otherwise.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD. The key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO. The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5 and 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored.\n\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for \n Kubernetes® that supports configuration of address pools for load balancer services.\n\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"string"},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"string"}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"routingResource":{"description":"Network resources that provide the forwarding/routing capabilities associated to the network resource realizing this VL.\n","type":"array","items":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The information about the VIM or CISM connection referenced by the VIM connection id is known to the VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId.\n\n* NOTE 2: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. When the container\n infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would \n correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, \n PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 3: When the container infrastructure service is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 2.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}}},"modificationsTriggeredByVnfPkgChange":{"description":"This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource when changing the current VNF package. The attributes that can be included consist of those requested to be modified explicitly in the \"ChangeCurrentVnfPkgRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly during the operation.\nNOTE 1:\tThis attribute represents the delta (semantics as per IETF RFC 7396, JSON Merge Patch) between the value \n of the attribute at the start of the \"Change current VNF package\" operation and the value of the attribute \n at its completion.\nNOTE 2:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) was modified implicitly \n during the related operation and contains a copy of the value of the related attribute from the VNFD in the \n VNF Package identified by the \"vnfdId\" attribute.\n","type":"object","properties":{"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"If present, this attribute signals the new value of the \"vnfProvider\" attribute in \"VnfInstance\". See note 2.\n","type":"string"},"vnfProductName":{"description":"If present, this attribute signals the new value of the \"vnfProductName\" attribute in \"VnfInstance\". See note 2.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"}}},"error":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}},"_links":{"description":"This type represents the links to resources that a notification can contain.\n","type":"object","required":["vnfInstance","subscription"],"properties":{"vnfInstance":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"subscription":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfLcmOpOcc":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true},"VnfIdentifierCreationNotification":{"description":"A notification about lifecycle changes triggered by a VNF LCM operation occurrence.\n","content":{"application/json":{"schema":{"description":"This type represents a VNF identifier creation notification, which informs the receiver of the creation of a new \"Individual VNF instance\" resource and the associated VNF instance identifier. This notification shall be triggered by the VNFM when it has created an \"Individual VNF instance\" resource and the associated VNF instance identifier.\n","type":"object","required":["id","notificationType","subscriptionId","timeStamp","vnfInstanceId","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"VnfIdentifierCreationNotification\" for this notification type.\n","type":"string","enum":["VnfIdentifierCreationNotification"]},"subscriptionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"_links":{"description":"This type represents the links to resources that a notification can contain.\n","type":"object","required":["vnfInstance","subscription"],"properties":{"vnfInstance":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"subscription":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfLcmOpOcc":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true},"VnfIdentifierDeletionNotification":{"description":"A notification about the deletion of a VNF identifier and the related \"Individual VNF instance\" resource.\n","content":{"application/json":{"schema":{"description":"This type represents a VNF identifier creation notification, which informs the receiver of the creation of a new \"Individual VNF instance\" resource and the associated VNF instance identifier. This notification shall be triggered by the VNFM when it has created an \"Individual VNF instance\" resource and the associated VNF instance identifier.\n","type":"object","required":["id","notificationType","subscriptionId","timeStamp","vnfInstanceId","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"VnfIdentifierCreationNotification\" for this notification type.\n","type":"string","enum":["VnfIdentifierCreationNotification"]},"subscriptionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"_links":{"description":"This type represents the links to resources that a notification can contain.\n","type":"object","required":["vnfInstance","subscription"],"properties":{"vnfInstance":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"subscription":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfLcmOpOcc":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true}},"responses":{"VNFLCMNotification.Get.204":{"description":"204 NO CONTENT\nShall be returned to indicate the notification endpoint has been tested successfully. The response body\nshall be empty.\n","headers":{"Version":{"description":"Version of the API used in the response.\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{}},"VNFLCMNotification.Post.204":{"description":"204 NO CONTENT\nShall be returned when the notification has been delivered successfully. The response body shall be empty.\n","headers":{"Version":{"description":"Version of the API used in the response.\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{}}}}} diff --git a/v5.3.1/SOL002-VNFLifecycleManagementNotification-API.yaml b/v5.3.1/SOL002-VNFLifecycleManagementNotification-API.yaml new file mode 100644 index 00000000..c76e4ed2 --- /dev/null +++ b/v5.3.1/SOL002-VNFLifecycleManagementNotification-API.yaml @@ -0,0 +1,6703 @@ +openapi: 3.0.2 +info: + title: SOL002 - VNF Lifecycle Management Notification interface + description: | + SOL002 - VNF Lifecycle Management Notification interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '2.16.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 002 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/05.03.01_60/gs_NFV-SOL002v050301p.pdf +servers: + - url: 'http://127.0.0.1/callback/v2' + - url: 'https://127.0.0.1/callback/v2' +paths: + /URI_is_provided_by_the_client_when_creating_the_subscription-VnfLcmOperationOccurrenceNotification: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The GET method allows the server to test the notification endpoint that + is provided by the API consumer, + + e.g. during subscription. See clause 5.4.20.3.2. + responses: + '204': + $ref: '#/components/responses/VNFLCMNotification.Get.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + The POST method delivers a notification from the API producer to an API + consumer. The API consumer shall have + + previously created an "Individual subscription" resource with a matching + filter. See clause 5.4.20.3.1. + parameters: + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/VnfLcmOperationOccurrenceNotification' + responses: + '204': + $ref: '#/components/responses/VNFLCMNotification.Post.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /URI_is_provided_by_the_client_when_creating_the_subscription-VnfIdentifierCreationNotification: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The GET method allows the server to test the notification endpoint that + is provided by the API consumer, + + e.g. during subscription. See clause 5.4.20.3.2. + responses: + '204': + $ref: '#/components/responses/VNFLCMNotification.Get.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + The POST method delivers a notification from the API producer to an API + consumer. The API consumer shall have + + previously created an "Individual subscription" resource with a matching + filter. See clause 5.4.20.3.1. + parameters: + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/VnfIdentifierCreationNotification' + responses: + '204': + $ref: '#/components/responses/VNFLCMNotification.Post.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /URI_is_provided_by_the_client_when_creating_the_subscription-VnfIdentifierDeletionNotification: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The GET method allows the server to test the notification endpoint that + is provided by the API consumer, + + e.g. during subscription. See clause 5.4.20.3.2. + responses: + '204': + $ref: '#/components/responses/VNFLCMNotification.Get.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + The POST method delivers a notification from the API producer to an API + consumer. The API consumer shall have + + previously created an "Individual subscription" resource with a matching + filter. See clause 5.4.20.3.1. + parameters: + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/VnfIdentifierDeletionNotification' + responses: + '204': + $ref: '#/components/responses/VNFLCMNotification.Post.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + requestBodies: + VnfLcmOperationOccurrenceNotification: + description: > + A notification about lifecycle changes triggered by a VNF LCM operation + occurrence. + content: + application/json: + schema: + description: "This type represents a VNF lifecycle management operation occurrence notification, which informs the receiver of changes in the VNF lifecycle caused by a VNF LCM operation occurrence. The support of the notification is mandatory. This notification shall be triggered by the VNFM when there is a change in the VNF lifecycle caused by a VNF LCM operation occurrence, including: * Instantiation of the VNF * Scaling of the VNF instance (including auto-scaling) * Healing of the VNF instance (including auto-healing) * Change of the state of the VNF instance (i.e. Operate VNF) * Change of the deployment flavour of the VNF instance * Change of the external connectivity of the VNF instance * Selection of deployable modules of the VNF instance * Termination of the VNF instance * Modification of VNF instance information and/or VNF configurable\n properties through the \"PATCH\" method on the \"Individual VNF instance\"\n resource.\nIf this is the initial notification about the start of a VNF LCM operation occurrence, it is assumed that the notification is sent by the VNFM before any action (including sending the grant request) is taken as part of the LCM operation. Due to possible race conditions, the \"start\" notification, the grant request and the LCM operation acknowledgment can arrive in any order at the NFVO, and the NFVO shall be able to handle such a situation. If this is a notification about a final or intermediate result state of a VNF LCM operation occurrence, the notification shall be sent after all related actions of the LCM operation that led to this state have been executed. The new state shall be set in the \"Individual VNF LCM operation occurrence\" resource before the notification about the state change is sent. * NOTE 1:\tShall be present if the \"notificationStatus\" is set to \"RESULT\", the \"verbosity\" attribute is set\n to \"FULL\" and the operation has performed any resource modification. Shall be absent otherwise.\n This attribute contains information about the cumulative changes to virtualised resources that\n were performed so far by the VNF LCM operation occurrence and by any of the error handling\n procedures for that operation occurrence.\n NOTE 2:\tFor a particular affected VL, there shall be as many \"AffectedVirtualLink\" entries as needed\n for signalling the different types of changes, i.e. one per virtual link and change type.\n For instance, in the case of signaling affected VL instances involving the addition of a particular\n VL instance with links ports, one \"AffectedVirtualLink\" entry signals the addition of the VL by using\n the \"changeType\" attribute of \"AffectedVirtualLink\" structure equal to \"ADDED\", and another\n \"AffectedVirtualLink\" entry signals the addition of VNF link ports of the VL by using the\n \"changeType\" equal to \"LINK_PORT_ADDED\".\n NOTE 3: Not more than one of changedInfo and modificationsTriggeredByVnfPkgChange shall be present.\n" + type: object + required: + - id + - notificationType + - subscriptionId + - timeStamp + - notificationStatus + - operationState + - vnfInstanceId + - operation + - isAutomaticInvocation + - vnfLcmOpOccId + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall be + set to "VnfLcmOperationOccurrenceNotification" for this + notification type. + type: string + enum: + - VnfLcmOperationOccurrenceNotification + subscriptionId: + description: | + An identifier with the intention of being globally unique. + type: string + timeStamp: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + notificationStatus: + description: > + Indicates whether this notification reports about the start of + a lifecycle operation or the result of a lifecycle operation. + Permitted values: * START: Informs about the start of the VNF + LCM operation + occurrence. + * RESULT: Informs about the final or intermediate result of + the VNF + LCM operation occurrence. + type: string + enum: + - START + - RESULT + operationState: + description: > + STARTING: The LCM operation is starting. PROCESSING: The LCM + operation is currently in execution. COMPLETED: The LCM + operation has been completed successfully. FAILED_TEMP: The + LCM operation has failed and execution has stopped, but the + execution of the operation is not considered to be closed. + FAILED: The LCM operation has failed and it cannot be retried + or rolled back, as it is determined that such action won't + succeed. ROLLING_BACK: The LCM operation is currently being + rolled back. ROLLED_BACK: The LCM operation has been + successfully rolled back, i.e. The state of the VNF prior to + the original operation invocation has been restored as closely + as possible. + type: string + enum: + - STARTING + - PROCESSING + - COMPLETED + - FAILED_TEMP + - FAILED + - ROLLING_BACK + - ROLLED_BACK + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + operation: + description: > + The enumeration LcmOpType defines the permitted values to + represent VNF lifecycle operation types in VNF lifecycle + management operation occurrence resources and VNF lifecycle + management operation occurrence notifications. + + Value | Description ------|------------ INSTANTIATE | + Represents the "Instantiate VNF" LCM operation. SCALE | + Represents the "Scale VNF" LCM operation. SCALE_TO_LEVEL | + Represents the "Scale VNF to Level" LCM operation. + CHANGE_FLAVOUR | Represents the "Change VNF Flavour" LCM + operation. TERMINATE | Represents the "Terminate VNF" LCM + operation. HEAL | Represents the "Heal VNF" LCM operation. + OPERATE | Represents the "Operate VNF" LCM operation. + CHANGE_EXT_CONN | Represents the "Change external VNF + connectivity" LCM operation. MODIFY_INFO | Represents the + "Modify VNF Information" LCM operation. CREATE_SNAPSHOT | + Represents the "Create VNF Snapshot" LCM operation. + REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot" + LCM operation. CHANGE_VNFPKG | Represents the "Change current + VNF package" LCM operation. SELECT_DEPL_MODS | Represents the + "Select VNF deployable modules" LCM operation + type: string + enum: + - INSTANTIATE + - SCALE + - SCALE_TO_LEVEL + - CHANGE_FLAVOUR + - TERMINATE + - HEAL + - OPERATE + - CHANGE_EXT_CONN + - MODIFY_INFO + - CREATE_SNAPSHOT + - REVERT_TO_SNAPSHOT + - CHANGE_VNFPKG + - SELECT_DEPL_MODS + isAutomaticInvocation: + description: > + Set to true if this VNF LCM operation occurrence has been + triggered by an automated procedure inside the VNFM (i.e. + ScaleVnf / ScaleVnfToLevel triggered by auto-scale, or HealVnf + triggered by auto-heal). Set to false otherwise. + type: boolean + verbosity: + description: > + The enumeration LcmOpOccNotificationVerbosityType provides + values to control the verbosity of LCM operation occurrence + notifications. * FULL: This signals a full notification which + contains all change details. * SHORT: This signals a short + notification which omits large-volume change details to reduce + the size of data to + be sent via the notification mechanism. + type: string + enum: + - FULL + - SHORT + vnfLcmOpOccId: + description: | + An identifier with the intention of being globally unique. + type: string + affectedVnfcs: + description: > + Information about VNFC instances that were affected during the + lifecycle operation. See note 1. + type: array + items: + description: > + This type provides information about added, deleted, + modified and temporary VNFCs. + type: object + required: + - id + - vduId + - changeType + - computeResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + vduId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: > + Signals the type of change. Permitted values: * ADDED * + REMOVED * MODIFIED * TEMPORARY For a temporary resource, + an AffectedVnfc structure exists as long as the + temporary resource exists. + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is known + to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service is a + Kubernetes® instance the resourceId shall be populated + in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + affectedVnfcCpIds: + description: > + Identifiers of CP(s) of the VNFC instance that were + affected by the change. Shall be present for those + affected CPs of the VNFC instance that are associated to + an external CP of the VNF instance. May be present for + further affected CPs of the VNFC instance. + type: array + items: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + addedStorageResourceIds: + description: > + References to VirtualStorage resources that have been + added. Each value refers to a VirtualStorageResourceInfo + item in the VnfInstance that was added to the VNFC. It + shall be provided if at least one storage resource was + added to the VNFC. + type: array + items: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + removedStorageResourceIds: + description: > + References to VirtualStorage resources that have been + removed. The value contains the identifier of a + VirtualStorageResourceInfo item that has been removed + from the VNFC, and might no longer exist in the + VnfInstance. It shall be provided if at least one + storage resource was removed from the VNFC. + type: array + items: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + affectedVirtualLinks: + description: > + Information about VL instances that were affected during the + lifecycle operation. See note 1 and note 2. + type: array + items: + description: "This type provides information about added, deleted, modified and temporary VLs, and added or removed VNF link ports.\nNOTE:\tWhen signalling the addition (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) of VNF link ports, \n the \"networkResource\" attribute refers to the affected virtual link instance, not the link port \n instance. The resource handles of the affected VNF link ports can be found by dereferencing the \n identifiers in the \"vnfLinkPortIds\" attribute.\n" + type: object + required: + - id + - vnfVirtualLinkDescId + - changeType + - networkResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + vnfVirtualLinkDescId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: > + Signals the type of change. Permitted values: * ADDED * + REMOVED * MODIFIED * TEMPORARY * LINK_PORT_ADDED * + LINK_PORT_REMOVED For a temporary resource, an + AffectedVirtualLink structure exists as long as the + temporary resource exists. When signalling the addition + (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) of VNF + link ports, the "networkResource" attribute refers to + the affected virtual link instance, not the link port + instance. The resource handles of the affected VNF link + ports can be found by dereferencing the identifiers in + the "vnfLinkPortIds" attribute. + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + - LINK_PORT_ADDED + - LINK_PORT_REMOVED + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is known + to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service is a + Kubernetes® instance the resourceId shall be populated + in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + vnfLinkPortIds: + description: > + Identifiers of the link ports of the affected VL related + to the change. Each identifier references a + "VnfLinkPortInfo" structure. + + Shall be set when changeType is equal to + "LINK_PORT_ADDED" or "LINK_PORT_REMOVED", and the + related "VnfLinkPortInfo" structures are present (case + "added") or have been present (case "removed") in the + "VnfVirtualLinkResourceInfo" or + "ExtManagedVirtualLinkInfo" structures that are + represented by the "vnfVirtualLinkResourceInfo" or + "extManagedVirtualLinkInfo" attribute in the + "VnfInstance" structure. See note. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + affectedExtLinkPorts: + description: > + Information about external VNF link ports that were affected + during the lifecycle operation. See note 1. + type: array + items: + description: > + This type provides information about added and deleted + external link ports (link ports attached to external virtual + links). + type: object + required: + - id + - changeType + - extCpInstanceId + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: "Signals the type of change. Permitted values: -\tADDED - MODIFIED -\tREMOVED\n" + type: string + enum: + - ADDED + - MODIFIED + - REMOVED + extCpInstanceId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is known + to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service is a + Kubernetes® instance the resourceId shall be populated + in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + affectedVirtualStorages: + description: > + Information about virtualised storage instances that were + affected during the lifecycle operation. See note 1. + type: array + items: + description: > + This type provides information about added, deleted, + modified and temporary virtual storage resources. + type: object + required: + - id + - virtualStorageDescId + - changeType + - storageResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + virtualStorageDescId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: > + Signals the type of change. Permitted values: * ADDED * + REMOVED * MODIFIED * TEMPORARY For a temporary resource, + an AffectedVirtualStorage structure exists as long as + the temporary resource exists. + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is known + to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service is a + Kubernetes® instance the resourceId shall be populated + in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + changedInfo: + description: "This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource. The attributes that can be included consist of those requested to be modified explicitly in the \"VnfInfoModificationRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly e.g. when modifying the referenced VNF package. * NOTE:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute)\n was modified implicitly following a request to modify the \"vnfdId\" attribute, by\n copying the value of this attribute from the VNFD in the VNF Package identified\n by the \"vnfdId\" attribute.\n" + type: object + properties: + vnfInstanceName: + description: > + If present, this attribute signals modifications of the + "vnfInstanceName" attribute in "VnfInstance" as defined in + clause 5.5.2.12.. + type: string + vnfInstanceDescription: + description: > + If present, this attribute signals modifications of the + "vnfInstanceDescription" attribute in "VnfInstance", as + defined in clause 5.5.2.12.. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfProvider: + description: > + If present, this attribute signals modifications of the + "vnfProvider" attribute in "VnfInstance". See note. + type: string + vnfProductName: + description: > + If present, this attribute signals modifications of the + "vnfProductName" attribute in "VnfInstance". See note. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vnfcInfoModifications: + description: > + If present, this attribute signals modifications of + certain entries in the "vnfcInfo" attribute array in the + "instantiatedVnfInfo" attribute of "VnfInstance", as + defined in clause 5.5.2.12. + type: array + items: + description: "This type represents modifications of an entry in an array of \"VnfcInfo\" objects. * NOTE:\tThe attribute \"id\" in this data type represents the same identifier as the attribute\n \"vnfcInstanceId\" in other related data types in the present document. For reasons of backward\n compatibility, this misalignment is not corrected.\n" + type: object + required: + - id + - vnfcConfigurableProperties + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfcConfigurableProperties: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + affectedVipCps: + description: > + Information about virtual IP CP instances that were affected + during the execution of the lifecycle management operation, if + this notification represents the result of a lifecycle + management operation occurrence. Shall be present if the + "notificationStatus" is set to "RESULT", the "verbosity" + attribute is set to "FULL" and the operation has made any + changes to the VIP CP instances of the VNF instance. Shall be + absent otherwise. Only information about VIP CP instances that + have been added, deleted or modified shall be provided. + type: array + items: + description: > + This type provides information about added, deleted and + modified virtual IP CP instances. + type: object + required: + - cpInstanceId + - cpdId + - changeType + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: "Signals the type of change. Permitted values: -\tADDED -\tREMOVED -\tMODIFIED\n" + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + affectedVirtualCps: + description: > + Information about virtual CP instances that were affected + during the execution of the lifecycle management operation, + if this notification represents the result of a lifecycle + management operation occurrence. + + Shall be present if the "notificationStatus" is set to + "RESULT", the "verbosity" attribute is set to "FULL" and the + operation has made any changes to the virtual CP instances of + the VNF instance. Shall be absent otherwise. Only information + about virtual CP instances that have been added, deleted or + modified shall be provided. + type: array + items: + description: > + This type provides information about added, deleted and + modified virtual CP instances. + type: object + required: + - cpInstanceId + - cpdId + - changeType + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: | + Signals the type of change. + Permitted values: + - ADDED + - REMOVED + - MODIFIED + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + affectedCertificates: + description: > + Information about certificate content that were affected + during the execution of the lifecycle management operation, if + this notification represents the result of a lifecycle + management operation occurrence. Shall be present when using + delegation mode, otherwise shall be absent. This attribute + shall be supported when delegation mode in certificate + management is applicable. + type: array + items: + description: > + This type provides input information about added, deleted + and modified certificate contents. + type: object + required: + - certificateInfoId + - changeType + properties: + certificateInfoId: + description: > + An identifier with the intention of being globally + unique. + type: string + certificateBaseProfileId: + description: > + An identifier with the intention of being globally + unique. + type: string + securityPolicyId: + description: > + An identifier with the intention of being globally + unique. + type: string + cmfInfoId: + description: > + An identifier with the intention of being globally + unique. + type: string + certificateContentId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: | + Signals the type of change. + type: string + enum: + - ADD + - REMOVE + - MODIFY + changedExtConnectivity: + description: > + Information about changed external connectivity, if this + notification represents the result of a lifecycle operation + occurrence. Shall be present if the "notificationStatus" is + set to "RESULT" and the "operation" has made any change of the + external connectivity of the VNF instance. Shall be absent + otherwise. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is known + to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service is a + Kubernetes® instance the resourceId shall be populated + in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the current CP + configuration information for the connection of external + CPs to the external virtual link. See note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value \n is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig\n map entry may be used by an external CP instance different than the one that has used it before the\n operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\"\n operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP\n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster\n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the\n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for\n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only\n required to configure one \"cpConfig\" per \"cpdId\", not per VNFC instance. The case of using, for a scalable\n VDU, a cloud native template in the MCIOP that describes one single VNFC instance is not specified in the\n present document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. The + entries shall be applied by the VNFM according to + the rules of JSON Merge Patch (see IETF RFC 7396). + See notes 2, 3, 4, 5 and 6. In case of deleting an + external CP, the list of instances to be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the + CIS cluster is set up to be able to configure an external load balancer. Otherwise, it shall be ignored. + + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + extNetAttDefResource: + description: > + Network attachment definition resources that provide the + specification of the interface to attach connection + points to this VL. + type: array + items: + description: > + This type contains information related to a network + attachment definition resource that provides the + specification of the interface used to connect one or + multiple connection points to a secondary container + cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of being globally + unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure + service is a Kubernetes® instance the resourceId + shall be populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated to this + network attachment definition resource. Shall be + present when the network attachment definition + resource is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to this + network attachment definition resource. May be + present when the network attachment definition + resource is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + routingResource: + description: > + Network resources that provide the forwarding/routing + capabilities associated to the network resource + realizing this VL. + type: array + items: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The information about the VIM or CISM + connection referenced by the VIM connection id is + known to the + VNFM. Moreover, the identifier of the VIM connection provides scope to the resourceId. + + * NOTE 2: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. When the container + infrastructure service is a Kubernetes® instance the vimLevelResourceType is the type of resource, as would + correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, e.g.: Pod, + PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 3: When the container infrastructure service is + a Kubernetes® instance the resourceId shall be + populated in the + following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 2. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the CISM + and shall be absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + modificationsTriggeredByVnfPkgChange: + description: "This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource when changing the current VNF package. The attributes that can be included consist of those requested to be modified explicitly in the \"ChangeCurrentVnfPkgRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly during the operation.\nNOTE 1:\tThis attribute represents the delta (semantics as per IETF RFC 7396, JSON Merge Patch) between the value \n of the attribute at the start of the \"Change current VNF package\" operation and the value of the attribute \n at its completion.\nNOTE 2:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) was modified implicitly \n during the related operation and contains a copy of the value of the related attribute from the VNFD in the \n VNF Package identified by the \"vnfdId\" attribute.\n" + type: object + properties: + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfProvider: + description: > + If present, this attribute signals the new value of the + "vnfProvider" attribute in "VnfInstance". See note 2. + type: string + vnfProductName: + description: > + If present, this attribute signals the new value of the + "vnfProductName" attribute in "VnfInstance". See note 2. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + error: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + _links: + description: > + This type represents the links to resources that a + notification can contain. + type: object + required: + - vnfInstance + - subscription + properties: + vnfInstance: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + subscription: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfLcmOpOcc: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + VnfIdentifierCreationNotification: + description: > + A notification about lifecycle changes triggered by a VNF LCM operation + occurrence. + content: + application/json: + schema: + description: > + This type represents a VNF identifier creation notification, which + informs the receiver of the creation of a new "Individual VNF + instance" resource and the associated VNF instance identifier. + This notification shall be triggered by the VNFM when it has + created an "Individual VNF instance" resource and the associated + VNF instance identifier. + type: object + required: + - id + - notificationType + - subscriptionId + - timeStamp + - vnfInstanceId + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall be + set to "VnfIdentifierCreationNotification" for this + notification type. + type: string + enum: + - VnfIdentifierCreationNotification + subscriptionId: + description: | + An identifier with the intention of being globally unique. + type: string + timeStamp: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + _links: + description: > + This type represents the links to resources that a + notification can contain. + type: object + required: + - vnfInstance + - subscription + properties: + vnfInstance: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + subscription: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfLcmOpOcc: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + VnfIdentifierDeletionNotification: + description: > + A notification about the deletion of a VNF identifier and the related + "Individual VNF instance" resource. + content: + application/json: + schema: + description: > + This type represents a VNF identifier creation notification, which + informs the receiver of the creation of a new "Individual VNF + instance" resource and the associated VNF instance identifier. + This notification shall be triggered by the VNFM when it has + created an "Individual VNF instance" resource and the associated + VNF instance identifier. + type: object + required: + - id + - notificationType + - subscriptionId + - timeStamp + - vnfInstanceId + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall be + set to "VnfIdentifierCreationNotification" for this + notification type. + type: string + enum: + - VnfIdentifierCreationNotification + subscriptionId: + description: | + An identifier with the intention of being globally unique. + type: string + timeStamp: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + _links: + description: > + This type represents the links to resources that a + notification can contain. + type: object + required: + - vnfInstance + - subscription + properties: + vnfInstance: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + subscription: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfLcmOpOcc: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + responses: + VNFLCMNotification.Get.204: + description: > + 204 NO CONTENT + + Shall be returned to indicate the notification endpoint has been tested + successfully. The response body + + shall be empty. + headers: + Version: + description: | + Version of the API used in the response. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + content: {} + VNFLCMNotification.Post.204: + description: > + 204 NO CONTENT + + Shall be returned when the notification has been delivered successfully. + The response body shall be empty. + headers: + Version: + description: | + Version of the API used in the response. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + content: {} + diff --git a/v5.3.1/SOL002-VNFPerformanceManagement-API.json b/v5.3.1/SOL002-VNFPerformanceManagement-API.json new file mode 100644 index 00000000..4abc54f3 --- /dev/null +++ b/v5.3.1/SOL002-VNFPerformanceManagement-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL002 - VNF Perfomance Management interface","description":"SOL002 - VNF Performance Management interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"2.13.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 002 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/05.03.01_60/gs_NFV-SOL002v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/vnfpm/v2"},{"url":"https://127.0.0.1/vnfpm/v2"}],"paths":{"/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/pm_jobs":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The API consumer can use this method to retrieve information about PM jobs. See clause 6.4.2.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}},{"$ref":"#/components/parameters/filter_pm_jobs"},{"name":"all_fields","description":"Include all complex attributes in the response. See clause 5.3 of ETSI GS NFV-SOL 013 [6] for details. The VNFM shall support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"fields","description":"Complex attributes to be included into the response. See clause 5.3 of ETSI GS NFV-SOL 013 [6] for details. The VNFM should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"exclude_fields","description":"Complex attributes to be excluded from the response. See clause 5.3 of ETSI GS NFV-SOL 013 [6] for details. The VNFM should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"$ref":"#/components/parameters/exclude_default_pm_jobs"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [6] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/PmJobs.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"The POST method creates a PM job. See clause 6.4.2.3.1.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/PmJobCreationRequest"},"responses":{"201":{"$ref":"#/components/responses/PmJobs.Post.201"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/PmJobs.Post.422"},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/pm_jobs/{pmJobId}":{"parameters":[{"$ref":"#/components/parameters/PmJobId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The API consumer can use this method for reading an individual PM job. See clause 6.4.3.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualPmJob.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method terminates an individual PM job. See clause 6.4.3.3.5.\n","responses":{"204":{"$ref":"#/components/responses/IndividualPmJob.Delete.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method allows to modify an \"individual PM job\" resource. See clause 6.4.3.3.4.\n","parameters":[{"name":"If-Unmodified-Since","description":"Used to make the request method conditional on the selected resource representation's last modification date being earlier than or equal to the date provided in the field-value. If the condition is not met, the request fails with a \"412 Precondition Failed\" response.\n","required":false,"in":"header","schema":{"type":"string","format":"date-time"}},{"name":"If-Match","description":"Used to make the request method conditional on the recipient origin server either having at least one current representation of the target resource, when the field-value is \"*\", or having a current representation of the target resource that has an entity-tag matching a member of the list of entity-tags provided in the field-value. If the condition is not met, the request fails with a \"412 Precondition Failed\" response.\n","required":false,"in":"header","schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/PmJobModificationRequest"},"responses":{"200":{"$ref":"#/components/responses/IndividualPmJob.Patch.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"409 CONFLICT\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"412 PRECONDITION FAILED\nError: 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/IndividualPmJob.Patch.422"},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/pm_jobs/{pmJobId}/reports/{reportId}":{"parameters":[{"$ref":"#/components/parameters/PmJobId"},{"$ref":"#/components/parameters/ReportId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The API consumer can use this method for reading an individual performance report. See clause 6.4.4.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualPmJobReport.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/thresholds":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The API cosumer can use this method to query information about thresholds. See clause 6.4.5.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"$ref":"#/components/parameters/filter_thresholds"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [6] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/Thresholds.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"The POST method can be used by API consumer to create a threshold. See clause 6.4.5.3.1.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/ThresholdCreationRequest"},"responses":{"201":{"$ref":"#/components/responses/Thresholds.Post.201"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/Thresholds.Post.422"},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/thresholds/{thresholdId}":{"parameters":[{"$ref":"#/components/parameters/ThresholdId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The client can use this method for reading an individual threshold. See clause 6.4.6.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualThreshold.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method allows to delete a threshold. See clause 6.4.6.3.5.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"204":{"$ref":"#/components/responses/IndividualThreshold.Delete.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method allows to modify an \"Individual threshold\" resource. See clause 6.4.6.3.4.\n","parameters":[{"name":"If-Unmodified-Since","description":"Used to make the request method conditional on the selected resource representation's last modification date being earlier than or equal to the date provided in the field-value. If the condition is not met, the request fails with a \"412 Precondition Failed\" response.\n","required":false,"in":"header","schema":{"type":"string","format":"date-time"}},{"name":"If-Match","description":"Used to make the request method conditional on the recipient origin server either having at least one current representation of the target resource, when the field-value is \"*\", or having a current representation of the target resource that has an entity-tag matching a member of the list of entity-tags provided in the field-value. If the condition is not met, the request fails with a \"412 Precondition Failed\" response.\n","required":false,"in":"header","schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/ThresholdModificationRequest"},"responses":{"200":{"$ref":"#/components/responses/IndividualThreshold.Patch.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"409 CONFLICT\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"412 PRECONDITION FAILED\nError: 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/IndividualThreshold.Patch.422"},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"parameters":{"filter_thresholds":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013. The VNFM shall support receiving this parameter as part of the URI query string. The API consumer may supply this parameter. All attribute names that appear in the Thresholds data type and in data types referenced from it shall be supported by the VNFM in the filter expression.\n","in":"query","required":false,"schema":{"type":"string"}},"exclude_default_pm_jobs":{"name":"exclude_default","in":"query","description":"Indicates to exclude the following complex attributes from the response. See clause 5.3 of ETSI GS NFV-SOL 013 for details. The VNFM shall support this parameter. The following attributes shall be excluded from the PmJob structure in the response body if this parameter is provided, or none of the parameters \"all_fields\", \"fields\", \"exclude_fields\", \"exclude_default\" are provided: - reports\n","required":false,"schema":{"type":"string"}},"filter_pm_jobs":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013. The VNFM shall support receiving this parameter as part of the URI query string. The API consumer may supply this parameter. All attribute names that appear in the PmJob and in data types referenced from it shall be supported by the VNFM in the filter expression.\n","in":"query","required":false,"schema":{"type":"string"}},"PmJobId":{"name":"pmJobId","in":"path","description":"Identifier of the PM job. This identifier can be retrieved from the resource referenced by the \"Location\" HTTP\nheader in the response to a POST request creating a new PM job resource. It can also be retrieved from the \"id\"\nattribute in the message content of that response.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"ReportId":{"name":"reportId","in":"path","description":"Identifier of the performance report.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"ThresholdId":{"name":"thresholdId","in":"path","description":"Identifier of the threshold. This identifier can be retrieved from the resource referenced by the \"Location\"\nHTTP header in the response to a POST request creating a new threshold resource. It can also be retrieved from\nthe \"id\" attribute in the message content of that response.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}}},"requestBodies":{"PmJobCreationRequest":{"description":"The VNF creation parameters","content":{"application/json":{"schema":{"description":"This type represents a request to create a PM job.\n","type":"object","required":["objectType","objectInstanceIds","criteria","callbackUri"],"properties":{"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceIds":{"description":"Identifiers of the measured object instances for which performance information is requested to be collected.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance for which performance information is requested to be collected. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027for the related measured object type. If this attribute is present, the cardinality of the \"objectInstanceIds\" attribute shall be 1. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV IFA 027 for the related measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents collection criteria for PM jobs.\nNOTE 1:\tAt the end of each reportingPeriod, the API producer will inform the API consumer about availability of the \n performance data collected for each completed collection period during this reportingPeriod. \n The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance \n data for the collection periods within one reporting period are reported together.\nNOTE 2:\tIn particular when choosing short collection and reporting periods, the number of PM jobs that can be supported \n depends on the capability of the producing entity.\n","type":"object","required":["collectionPeriod","reportingPeriod"],"properties":{"performanceMetric":{"description":"This defines the types of performance metrics for the specified object instances. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"performanceMetricGroup":{"description":"Group of performance metrics. A metric group is a pre-defined list of metrics, known to the API producer that it can decompose to individual metrics. Valid values are specified as \"Measurement Group\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"collectionPeriod":{"description":"SSpecifies the periodicity at which the API producer will collect performance information. The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingPeriod":{"description":"Specifies the periodicity at which the API producer will report to the API consumer about performance information. The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingBoundary":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE 1 : The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between\n subscriptions. The value of clientPassword should be generated by a random process.\n* NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT which uses mutual authentication based on X.509 certificates, this mode which uses client password to authenticate may be used in the access token request\n toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations\n (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details.\n* NOTE 3: The following values that were included up to version 3.4.1 of the present document have been removed: \"BASIC\" (to signal the use of the basic HTTP authentication) has been removed because it is insecure.\n \"TLS_CERT\" to signal an alternative non-token based authorization method using TLS certificates has been\n removed because the method is no longer supported.\n* NOTE 4: The client certificate is established by means outside the scope of the present document.\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values (see note 3): * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use\n an OAuth 2.0 token, obtained using the client\n credentials grant type after authenticating\n using client identifier and client password\n towards the token endpoint.\n* OAUTH2_CLIENT_CERT: In every HTTP request to the notification endpoint, use an\n OAuth 2.0 token, obtained using the client\n credentials grant type after mutually\n authenticating using client identifier and X.509\n certificates towards the token endpoint.\n","type":"array","items":{"type":"string","enum":["OAUTH2_CLIENT_CREDENTIALS","OAUTH2_CLIENT_CERT"]}},"paramsOauth2ClientCert":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CERT.\nShall be present if authType is \"OAUTH2_CLIENT_CERT\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\n","type":"object","required":["clientId","certificateRef","tokenEndpoint"],"properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint.\n","type":"string"},"certificateRef":{"description":"Fingerprint of the client certificate. The hash function shall use SHA256 or higher. See note 4.\n","type":"string","required":["type","value"],"properties":{"type":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"value":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS.\nShall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\nSee note 2.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"clientPassword":{"description":"Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true},"PmJobModificationRequest":{"description":"Parameters for the PM job modification","content":{"application/merge-patch+json":{"schema":{"description":"This type represents modifications to a PM job.\nNOTE:\tAt least one of the attributes defined in this type shall be present in request bodies.\n","type":"object","oneOf":[{"required":["callbackUri"]},{"required":["authentication"]}],"properties":{"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE 1 : The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between\n subscriptions. The value of clientPassword should be generated by a random process.\n* NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT which uses mutual authentication based on X.509 certificates, this mode which uses client password to authenticate may be used in the access token request\n toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations\n (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details.\n* NOTE 3: The following values that were included up to version 3.4.1 of the present document have been removed: \"BASIC\" (to signal the use of the basic HTTP authentication) has been removed because it is insecure.\n \"TLS_CERT\" to signal an alternative non-token based authorization method using TLS certificates has been\n removed because the method is no longer supported.\n* NOTE 4: The client certificate is established by means outside the scope of the present document.\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values (see note 3): * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use\n an OAuth 2.0 token, obtained using the client\n credentials grant type after authenticating\n using client identifier and client password\n towards the token endpoint.\n* OAUTH2_CLIENT_CERT: In every HTTP request to the notification endpoint, use an\n OAuth 2.0 token, obtained using the client\n credentials grant type after mutually\n authenticating using client identifier and X.509\n certificates towards the token endpoint.\n","type":"array","items":{"type":"string","enum":["OAUTH2_CLIENT_CREDENTIALS","OAUTH2_CLIENT_CERT"]}},"paramsOauth2ClientCert":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CERT.\nShall be present if authType is \"OAUTH2_CLIENT_CERT\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\n","type":"object","required":["clientId","certificateRef","tokenEndpoint"],"properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint.\n","type":"string"},"certificateRef":{"description":"Fingerprint of the client certificate. The hash function shall use SHA256 or higher. See note 4.\n","type":"string","required":["type","value"],"properties":{"type":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"value":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS.\nShall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\nSee note 2.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"clientPassword":{"description":"Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true},"ThresholdCreationRequest":{"description":"Request parameters to create a new \"Individual threshold\" resource.\n","content":{"application/json":{"schema":{"description":"This type represents a request to create a threshold.\n","type":"object","required":["objectType","objectInstanceId","criteria","callbackUri"],"properties":{"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance associated with this threshold. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents criteria that define a threshold.\nNOTE 1:\tIn the present document, simple thresholds are defined. The definition of additional threshold types is left for \n future specification.\nNOTE 2:\tThe hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create \n a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or \n reject the request). \n","type":"object","required":["performanceMetric","thresholdType"],"properties":{"performanceMetric":{"description":"Defines the performance metric associated with the threshold. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"thresholdType":{"description":"Type of threshold. This attribute determines which other attributes are present in the data structure.\nPermitted values: -\tSIMPLE: Single-valued static threshold. See note 1.\n","type":"string","enum":["SIMPLE"]},"simpleThresholdDetails":{"description":"Details of a simple threshold. Shall be present if thresholdType=\"SIMPLE\".\n","type":"object","required":["thresholdValue","hysteresis"],"properties":{"thresholdValue":{"description":"The threshold value. Shall be represented as a floating point number.\n","type":"number","format":"float"},"hysteresis":{"description":"The hysteresis of the threshold. Shall be represented as a non-negative floating point number.\nA notification with crossing direction \"UP\" will be generated if the measured value reaches or exceeds \"thresholdValue\" + \"hysteresis\". A notification with crossing direction \"DOWN\" will be generated if the measured value reaches or undercuts \"thresholdValue\" - \"hysteresis\". See note 2.\n","type":"number","minimum":0,"maximum":1024,"format":"float"}}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE 1 : The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between\n subscriptions. The value of clientPassword should be generated by a random process.\n* NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT which uses mutual authentication based on X.509 certificates, this mode which uses client password to authenticate may be used in the access token request\n toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations\n (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details.\n* NOTE 3: The following values that were included up to version 3.4.1 of the present document have been removed: \"BASIC\" (to signal the use of the basic HTTP authentication) has been removed because it is insecure.\n \"TLS_CERT\" to signal an alternative non-token based authorization method using TLS certificates has been\n removed because the method is no longer supported.\n* NOTE 4: The client certificate is established by means outside the scope of the present document.\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values (see note 3): * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use\n an OAuth 2.0 token, obtained using the client\n credentials grant type after authenticating\n using client identifier and client password\n towards the token endpoint.\n* OAUTH2_CLIENT_CERT: In every HTTP request to the notification endpoint, use an\n OAuth 2.0 token, obtained using the client\n credentials grant type after mutually\n authenticating using client identifier and X.509\n certificates towards the token endpoint.\n","type":"array","items":{"type":"string","enum":["OAUTH2_CLIENT_CREDENTIALS","OAUTH2_CLIENT_CERT"]}},"paramsOauth2ClientCert":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CERT.\nShall be present if authType is \"OAUTH2_CLIENT_CERT\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\n","type":"object","required":["clientId","certificateRef","tokenEndpoint"],"properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint.\n","type":"string"},"certificateRef":{"description":"Fingerprint of the client certificate. The hash function shall use SHA256 or higher. See note 4.\n","type":"string","required":["type","value"],"properties":{"type":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"value":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS.\nShall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\nSee note 2.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"clientPassword":{"description":"Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true},"ThresholdModificationRequest":{"description":"Parameters for the threshold modification.","content":{"application/merge-patch+json":{"schema":{"description":"This type represents modifications to a threshold.\nNOTE:\tAt least one of the attributes defined in this type shall be present in request bodies.\n","type":"object","oneOf":[{"required":["callbackUri"]},{"required":["authentication"]}],"properties":{"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE 1 : The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between\n subscriptions. The value of clientPassword should be generated by a random process.\n* NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT which uses mutual authentication based on X.509 certificates, this mode which uses client password to authenticate may be used in the access token request\n toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations\n (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details.\n* NOTE 3: The following values that were included up to version 3.4.1 of the present document have been removed: \"BASIC\" (to signal the use of the basic HTTP authentication) has been removed because it is insecure.\n \"TLS_CERT\" to signal an alternative non-token based authorization method using TLS certificates has been\n removed because the method is no longer supported.\n* NOTE 4: The client certificate is established by means outside the scope of the present document.\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values (see note 3): * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use\n an OAuth 2.0 token, obtained using the client\n credentials grant type after authenticating\n using client identifier and client password\n towards the token endpoint.\n* OAUTH2_CLIENT_CERT: In every HTTP request to the notification endpoint, use an\n OAuth 2.0 token, obtained using the client\n credentials grant type after mutually\n authenticating using client identifier and X.509\n certificates towards the token endpoint.\n","type":"array","items":{"type":"string","enum":["OAUTH2_CLIENT_CREDENTIALS","OAUTH2_CLIENT_CERT"]}},"paramsOauth2ClientCert":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CERT.\nShall be present if authType is \"OAUTH2_CLIENT_CERT\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\n","type":"object","required":["clientId","certificateRef","tokenEndpoint"],"properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint.\n","type":"string"},"certificateRef":{"description":"Fingerprint of the client certificate. The hash function shall use SHA256 or higher. See note 4.\n","type":"string","required":["type","value"],"properties":{"type":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"value":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS.\nShall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\nSee note 2.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"clientPassword":{"description":"Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true}},"responses":{"PmJobs.Get.200":{"description":"200 OK\nShall be returned when information about zero or more PM jobs was queried successfully. The response body\nshall contain in an array the representations of zero or more PM jobs, as defined in clause 6.5.2.7.\nIf the \"filter\" URI parameter or one of the \"all_fields\", \"fields\" (if supported), \"exclude_fields\"\n(if supported) or \"exclude_default\" URI parameters was supplied in the request, the data in the response\nbody shall have been transformed according to the rules specified in clauses 5.2.2 and 5.3.2 of\nETSI GS NFV-SOL 013, respectively. If the VNFM supports alternative 2 (paging) according to clause 5.4.2.1\nof ETSI GS NFV-SOL 013for this resource, inclusion of the Link HTTP header in this response shall follow\nthe provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a PM job.\n","type":"object","required":["id","objectType","objectInstanceIds","criteria","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceIds":{"description":"Identifiers of the VNF instances for which performance information is collected.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance for which performance information is requested to be collected. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type. If this attribute is present, the cardinality of the \"objectInstanceIds\" attribute shall be 1. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV IFA 027 for the related measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents collection criteria for PM jobs.\nNOTE 1:\tAt the end of each reportingPeriod, the API producer will inform the API consumer about availability of the \n performance data collected for each completed collection period during this reportingPeriod. \n The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance \n data for the collection periods within one reporting period are reported together.\nNOTE 2:\tIn particular when choosing short collection and reporting periods, the number of PM jobs that can be supported \n depends on the capability of the producing entity.\n","type":"object","required":["collectionPeriod","reportingPeriod"],"properties":{"performanceMetric":{"description":"This defines the types of performance metrics for the specified object instances. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"performanceMetricGroup":{"description":"Group of performance metrics. A metric group is a pre-defined list of metrics, known to the API producer that it can decompose to individual metrics. Valid values are specified as \"Measurement Group\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"collectionPeriod":{"description":"SSpecifies the periodicity at which the API producer will collect performance information. The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingPeriod":{"description":"Specifies the periodicity at which the API producer will report to the API consumer about performance information. The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingBoundary":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"reports":{"description":"Information about available reports collected by this PM job.\n","type":"object","required":["href","readyTime"],"properties":{"href":{"description":"The URI where the report can be obtained.\n","type":"string","format":"url"},"readyTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"expiryTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"fileSize":{"description":"The size of the report file in bytes, if known.\n","type":"integer","minimum":0}}},"pmJobConnection":{"description":"An access information and interface information of PM job to monitor the PM of VNF instance by the VNFM. This can include for instance certain interface endpoint URI together with necessary credentials to access it.\n","type":"array","items":{"description":"The MonitoringConnection shall follow the indications. * NOTE:\tThe VNFM can be made aware of monitoring connection information, including their identifiers to \n be used by configuration means outside the scope of the present document (e.g. using relevant NFV-MANO management \n APIs as defined in ETSI GS NFV-SOL 009). \n","type":"object","required":["id","monitoringType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"monitoringType":{"description":"Type of monitoring way. VALUES: \n •\tVIM_CISM\n •\tEXTERNAL\n •\tPAAS\n","type":"string","enum":["VIM_CISM","EXTERNAL","PAAS"]},"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"objects":{"description":"Links to resources representing the measure object instances for which performance information is collected. Shall be present if the measured object instance information is accessible as a resource.\n","type":"array","items":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}}},"PmJobs.Post.201":{"description":"201 CREATED\nShall be returned when the PM job has been created successfully. The response body shall contain a\nrepresentation of the created PM job resource. The HTTP response shall include a \"Location\" HTTP header that\npoints to the created \"Individual PM job\" resource.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"The resource URI of the created PM Job","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{"application/json":{"schema":{"description":"This type represents a PM job.\n","type":"object","required":["id","objectType","objectInstanceIds","criteria","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceIds":{"description":"Identifiers of the VNF instances for which performance information is collected.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance for which performance information is requested to be collected. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type. If this attribute is present, the cardinality of the \"objectInstanceIds\" attribute shall be 1. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV IFA 027 for the related measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents collection criteria for PM jobs.\nNOTE 1:\tAt the end of each reportingPeriod, the API producer will inform the API consumer about availability of the \n performance data collected for each completed collection period during this reportingPeriod. \n The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance \n data for the collection periods within one reporting period are reported together.\nNOTE 2:\tIn particular when choosing short collection and reporting periods, the number of PM jobs that can be supported \n depends on the capability of the producing entity.\n","type":"object","required":["collectionPeriod","reportingPeriod"],"properties":{"performanceMetric":{"description":"This defines the types of performance metrics for the specified object instances. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"performanceMetricGroup":{"description":"Group of performance metrics. A metric group is a pre-defined list of metrics, known to the API producer that it can decompose to individual metrics. Valid values are specified as \"Measurement Group\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"collectionPeriod":{"description":"SSpecifies the periodicity at which the API producer will collect performance information. The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingPeriod":{"description":"Specifies the periodicity at which the API producer will report to the API consumer about performance information. The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingBoundary":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"reports":{"description":"Information about available reports collected by this PM job.\n","type":"object","required":["href","readyTime"],"properties":{"href":{"description":"The URI where the report can be obtained.\n","type":"string","format":"url"},"readyTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"expiryTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"fileSize":{"description":"The size of the report file in bytes, if known.\n","type":"integer","minimum":0}}},"pmJobConnection":{"description":"An access information and interface information of PM job to monitor the PM of VNF instance by the VNFM. This can include for instance certain interface endpoint URI together with necessary credentials to access it.\n","type":"array","items":{"description":"The MonitoringConnection shall follow the indications. * NOTE:\tThe VNFM can be made aware of monitoring connection information, including their identifiers to \n be used by configuration means outside the scope of the present document (e.g. using relevant NFV-MANO management \n APIs as defined in ETSI GS NFV-SOL 009). \n","type":"object","required":["id","monitoringType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"monitoringType":{"description":"Type of monitoring way. VALUES: \n •\tVIM_CISM\n •\tEXTERNAL\n •\tPAAS\n","type":"string","enum":["VIM_CISM","EXTERNAL","PAAS"]},"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"objects":{"description":"Links to resources representing the measure object instances for which performance information is collected. Shall be present if the measured object instance information is accessible as a resource.\n","type":"array","items":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"PmJobs.Post.422":{"description":"422 Unprocessable Content\n\nShall be returned upon the following error: The content type of the message content is supported\nand the message content of a request contains syntactically correct data but the data cannot be\nprocessed.\nThe general cause for this error and its handling is specified in clause 6.4 of ETSI GS NFV-SOL 013,\nincluding rules for the presence of the response body.\nSpecifically in case of this resource, the response code 422 shall also be returned if the VNFM has\ntested the Notification endpoint as described in clause 6.4.9.3.2 and the test has failed.\nIn this case, the \"detail\" attribute in the \"ProblemDetails\" structure shall convey more\ninformation about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualPmJob.Get.200":{"description":"200 OK\nShall be returned when information about an individual PM job has been ueried successfully. The response\nbody shall contain a representation of the \"Individual PM job\" resource.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"ETag":{"description":"Used to provide the current entity-tag for the selected resource representation. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string"}},"Last-Modified":{"description":"Used to provide a timestamp indicating the date and time at which the server believes the selected resource representation was last modified. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string","format":"date-time"}}},"content":{"application/json":{"schema":{"description":"This type represents a PM job.\n","type":"object","required":["id","objectType","objectInstanceIds","criteria","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceIds":{"description":"Identifiers of the VNF instances for which performance information is collected.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance for which performance information is requested to be collected. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type. If this attribute is present, the cardinality of the \"objectInstanceIds\" attribute shall be 1. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV IFA 027 for the related measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents collection criteria for PM jobs.\nNOTE 1:\tAt the end of each reportingPeriod, the API producer will inform the API consumer about availability of the \n performance data collected for each completed collection period during this reportingPeriod. \n The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance \n data for the collection periods within one reporting period are reported together.\nNOTE 2:\tIn particular when choosing short collection and reporting periods, the number of PM jobs that can be supported \n depends on the capability of the producing entity.\n","type":"object","required":["collectionPeriod","reportingPeriod"],"properties":{"performanceMetric":{"description":"This defines the types of performance metrics for the specified object instances. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"performanceMetricGroup":{"description":"Group of performance metrics. A metric group is a pre-defined list of metrics, known to the API producer that it can decompose to individual metrics. Valid values are specified as \"Measurement Group\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"collectionPeriod":{"description":"SSpecifies the periodicity at which the API producer will collect performance information. The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingPeriod":{"description":"Specifies the periodicity at which the API producer will report to the API consumer about performance information. The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingBoundary":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"reports":{"description":"Information about available reports collected by this PM job.\n","type":"object","required":["href","readyTime"],"properties":{"href":{"description":"The URI where the report can be obtained.\n","type":"string","format":"url"},"readyTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"expiryTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"fileSize":{"description":"The size of the report file in bytes, if known.\n","type":"integer","minimum":0}}},"pmJobConnection":{"description":"An access information and interface information of PM job to monitor the PM of VNF instance by the VNFM. This can include for instance certain interface endpoint URI together with necessary credentials to access it.\n","type":"array","items":{"description":"The MonitoringConnection shall follow the indications. * NOTE:\tThe VNFM can be made aware of monitoring connection information, including their identifiers to \n be used by configuration means outside the scope of the present document (e.g. using relevant NFV-MANO management \n APIs as defined in ETSI GS NFV-SOL 009). \n","type":"object","required":["id","monitoringType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"monitoringType":{"description":"Type of monitoring way. VALUES: \n •\tVIM_CISM\n •\tEXTERNAL\n •\tPAAS\n","type":"string","enum":["VIM_CISM","EXTERNAL","PAAS"]},"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"objects":{"description":"Links to resources representing the measure object instances for which performance information is collected. Shall be present if the measured object instance information is accessible as a resource.\n","type":"array","items":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"IndividualPmJob.Delete.204":{"description":"204 NO CONTENT\nShall be returned when the PM job has been deleted successfully. The response body shall be empty.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details\nif the corresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{}},"IndividualPmJob.Patch.200":{"description":"200 OK\nShall be returned when the request has been processed successfully. The response body shall contain a data\nstructure of type \"PmJobModifications\".\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"ETag":{"description":"Used to provide the current entity-tag for the selected resource representation. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string"}},"Last-Modified":{"description":"Used to provide a timestamp indicating the date and time at which the server believes the selected resource representation was last modified. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string","format":"date-time"}}},"content":{"application/json":{"schema":{"description":"This type represents modifications to a PM job.\nNOTE:\tAt least one of the attributes defined in this type shall be present in request bodies.\n","type":"object","oneOf":[{"required":["callbackUri"]},{"required":["authentication"]}],"properties":{"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE 1 : The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between\n subscriptions. The value of clientPassword should be generated by a random process.\n* NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT which uses mutual authentication based on X.509 certificates, this mode which uses client password to authenticate may be used in the access token request\n toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations\n (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details.\n* NOTE 3: The following values that were included up to version 3.4.1 of the present document have been removed: \"BASIC\" (to signal the use of the basic HTTP authentication) has been removed because it is insecure.\n \"TLS_CERT\" to signal an alternative non-token based authorization method using TLS certificates has been\n removed because the method is no longer supported.\n* NOTE 4: The client certificate is established by means outside the scope of the present document.\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values (see note 3): * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use\n an OAuth 2.0 token, obtained using the client\n credentials grant type after authenticating\n using client identifier and client password\n towards the token endpoint.\n* OAUTH2_CLIENT_CERT: In every HTTP request to the notification endpoint, use an\n OAuth 2.0 token, obtained using the client\n credentials grant type after mutually\n authenticating using client identifier and X.509\n certificates towards the token endpoint.\n","type":"array","items":{"type":"string","enum":["OAUTH2_CLIENT_CREDENTIALS","OAUTH2_CLIENT_CERT"]}},"paramsOauth2ClientCert":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CERT.\nShall be present if authType is \"OAUTH2_CLIENT_CERT\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\n","type":"object","required":["clientId","certificateRef","tokenEndpoint"],"properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint.\n","type":"string"},"certificateRef":{"description":"Fingerprint of the client certificate. The hash function shall use SHA256 or higher. See note 4.\n","type":"string","required":["type","value"],"properties":{"type":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"value":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS.\nShall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\nSee note 2.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"clientPassword":{"description":"Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualPmJob.Patch.422":{"description":"422 Unprocessable Content\n\nShall be returned upon the following error: The content type of the message content is supported\nand the message content of a request contains syntactically correct data but the data cannot be processed.\nThe general cause for this error and its handling is specified in clause 6.4 of ETSI GS NFV-SOL 013,\nincluding rules for the presence of the response body.\nSpecifically in case of this resource, the response code 422 shall also be returned if the VNFM has tested\nthe Notification endpoint as described in clause 6.4.9.3.2 and the test has failed.\nIn this case, the \"detail\" attribute in the \"ProblemDetails\" structure shall convey more information\nabout the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualPmJobReport.Get.200":{"description":"200 OK\nShall be returned when information of an individual performance report has been read successfully.\nThe response body shall contain a representation of the \"Individual performance report\" resource.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type defines the format of a performance report provided by the VNFM to the NFVO as a result of collecting performance information as part of a PM job.\nNOTE:\tThe sub-object allows to structure the measured object but is not to be confused with sub-counters which allow \n to structure the measurement value.\n\nEXAMPLE:\n Measured object: VnfInstanceXYZ\n Sub-object: VnfcInstance1\n Measurement: vCPU_utilization\n Sub-counters: vCPU utilization of each of the vCPUs of VnfcInstance1 (vCPU utilization.vCPU1, vCPU_utilization.vCPU2, etc.).\n","type":"object","required":["entries"],"properties":{"entries":{"description":"List of performance information entries. Each performance report entry is for a given metric of a given object (i.e. VNF instance), but can include multiple collected values.\n","type":"array","items":{"type":"object","required":["objectType","objectInstanceId","performanceMetric","performanceValue"],"properties":{"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"performanceMetric":{"description":"Name of the metric collected. This attribute shall contain the related \"Measurement Name\" value as defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"performanceValues":{"description":"List of performance values with associated timestamp.\n","type":"array","items":{"type":"object","required":["timeStamp","value"],"properties":{"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"value":{"description":"Value of the metric collected. The type of this attribute shall correspond to the related \"Measurement Unit\" as defined in clause 7.2. of ETSI GS NFV-IFA 027.\n","type":"object"},"context":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}}}}}}}},"Thresholds.Get.200":{"description":"200 OK\nInformation about zero or more thresholds was queried successfully.\nIf the \"filter\" URI parameter was supplied in the request, the data in the response body shall have\nbeen transformed according to the rules specified in clause 5.2.2 of ETSI GS NFV SOL 013.\nThe response body shall contain in an array the representations of zero or more thresholds,\nas defined in clause 6.5.2.9. If the VNFM supports alternative 2 (paging) according to clause 5.4.2.1\nof ETSI GS NFV-SOL 013 for this resource, inclusion of the Link HTTP header in this response shall\nfollow the provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if\nthe corresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a threshold.\n","type":"object","required":["id","objectType","objectInstanceId","criteria","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance associated with the threshold. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measurement type. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents criteria that define a threshold.\nNOTE 1:\tIn the present document, simple thresholds are defined. The definition of additional threshold types is left for \n future specification.\nNOTE 2:\tThe hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create \n a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or \n reject the request). \n","type":"object","required":["performanceMetric","thresholdType"],"properties":{"performanceMetric":{"description":"Defines the performance metric associated with the threshold. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"thresholdType":{"description":"Type of threshold. This attribute determines which other attributes are present in the data structure.\nPermitted values: -\tSIMPLE: Single-valued static threshold. See note 1.\n","type":"string","enum":["SIMPLE"]},"simpleThresholdDetails":{"description":"Details of a simple threshold. Shall be present if thresholdType=\"SIMPLE\".\n","type":"object","required":["thresholdValue","hysteresis"],"properties":{"thresholdValue":{"description":"The threshold value. Shall be represented as a floating point number.\n","type":"number","format":"float"},"hysteresis":{"description":"The hysteresis of the threshold. Shall be represented as a non-negative floating point number.\nA notification with crossing direction \"UP\" will be generated if the measured value reaches or exceeds \"thresholdValue\" + \"hysteresis\". A notification with crossing direction \"DOWN\" will be generated if the measured value reaches or undercuts \"thresholdValue\" - \"hysteresis\". See note 2.\n","type":"number","minimum":0,"maximum":1024,"format":"float"}}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"object":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"Thresholds.Post.201":{"description":"201 CREATED\nShall be returned when a threshold has been created successfully. The response body shall contain a\nrepresentation of the created \"Individual threshold\" resource. The HTTP response shall include a\n\"Location\" HTTP header that contains the resource URI of the created resource.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if\nthe corresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"The resource URI of the created threshold","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{"application/json":{"schema":{"description":"This type represents a threshold.\n","type":"object","required":["id","objectType","objectInstanceId","criteria","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance associated with the threshold. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measurement type. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents criteria that define a threshold.\nNOTE 1:\tIn the present document, simple thresholds are defined. The definition of additional threshold types is left for \n future specification.\nNOTE 2:\tThe hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create \n a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or \n reject the request). \n","type":"object","required":["performanceMetric","thresholdType"],"properties":{"performanceMetric":{"description":"Defines the performance metric associated with the threshold. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"thresholdType":{"description":"Type of threshold. This attribute determines which other attributes are present in the data structure.\nPermitted values: -\tSIMPLE: Single-valued static threshold. See note 1.\n","type":"string","enum":["SIMPLE"]},"simpleThresholdDetails":{"description":"Details of a simple threshold. Shall be present if thresholdType=\"SIMPLE\".\n","type":"object","required":["thresholdValue","hysteresis"],"properties":{"thresholdValue":{"description":"The threshold value. Shall be represented as a floating point number.\n","type":"number","format":"float"},"hysteresis":{"description":"The hysteresis of the threshold. Shall be represented as a non-negative floating point number.\nA notification with crossing direction \"UP\" will be generated if the measured value reaches or exceeds \"thresholdValue\" + \"hysteresis\". A notification with crossing direction \"DOWN\" will be generated if the measured value reaches or undercuts \"thresholdValue\" - \"hysteresis\". See note 2.\n","type":"number","minimum":0,"maximum":1024,"format":"float"}}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"object":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"Thresholds.Post.422":{"description":"422 Unprocessable Content\n\nShall be returned upon the following error: The content type of the message content is supported\nand the message content of a request contains syntactically correct data but the data cannot be processed.\nThe general cause for this error and its handling is specified in clause 6.4 of ETSI GS NFV-SOL 013,\nincluding rules for the presence of the response body.\nSpecifically in case of this resource, the response code 422 shall also be returned if the VNFM has tested\nthe Notification endpoint as described in clause 6.4.9.3.2 and the test has failed.\nIn this case, the \"detail\" attribute in the \"ProblemDetails\" structure shall convey more information\nabout the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualThreshold.Get.200":{"description":"200 OK\nShall be returned when information about an individual threshold has been queried successfully.\nThe response body shall contain a representation of the threshold.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"ETag":{"description":"Used to provide the current entity-tag for the selected resource representation. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string"}},"Last-Modified":{"description":"Used to provide a timestamp indicating the date and time at which the server believes the selected resource representation was last modified. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string","format":"date-time"}}},"content":{"application/json":{"schema":{"description":"This type represents a threshold.\n","type":"object","required":["id","objectType","objectInstanceId","criteria","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance associated with the threshold. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measurement type. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents criteria that define a threshold.\nNOTE 1:\tIn the present document, simple thresholds are defined. The definition of additional threshold types is left for \n future specification.\nNOTE 2:\tThe hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create \n a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or \n reject the request). \n","type":"object","required":["performanceMetric","thresholdType"],"properties":{"performanceMetric":{"description":"Defines the performance metric associated with the threshold. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"thresholdType":{"description":"Type of threshold. This attribute determines which other attributes are present in the data structure.\nPermitted values: -\tSIMPLE: Single-valued static threshold. See note 1.\n","type":"string","enum":["SIMPLE"]},"simpleThresholdDetails":{"description":"Details of a simple threshold. Shall be present if thresholdType=\"SIMPLE\".\n","type":"object","required":["thresholdValue","hysteresis"],"properties":{"thresholdValue":{"description":"The threshold value. Shall be represented as a floating point number.\n","type":"number","format":"float"},"hysteresis":{"description":"The hysteresis of the threshold. Shall be represented as a non-negative floating point number.\nA notification with crossing direction \"UP\" will be generated if the measured value reaches or exceeds \"thresholdValue\" + \"hysteresis\". A notification with crossing direction \"DOWN\" will be generated if the measured value reaches or undercuts \"thresholdValue\" - \"hysteresis\". See note 2.\n","type":"number","minimum":0,"maximum":1024,"format":"float"}}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"object":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualThreshold.Delete.204":{"description":"204 NO CONTENT\nShall be returned when the threshold was deleted successfully. The response body shall be empty.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if\nthe corresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{}},"IndividualThreshold.Patch.200":{"description":"200 OK\nShall be returned when the request has been processed successfully. The response body shall contain a data\nstructure of type \"ThresholdModifications\".\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"ETag":{"description":"Used to provide the current entity-tag for the selected resource representation. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string"}},"Last-Modified":{"description":"Used to provide a timestamp indicating the date and time at which the server believes the selected resource representation was last modified. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string","format":"date-time"}}},"content":{"application/json":{"schema":{"description":"This type represents modifications to a threshold.\nNOTE:\tAt least one of the attributes defined in this type shall be present in request bodies.\n","type":"object","oneOf":[{"required":["callbackUri"]},{"required":["authentication"]}],"properties":{"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE 1 : The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between\n subscriptions. The value of clientPassword should be generated by a random process.\n* NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT which uses mutual authentication based on X.509 certificates, this mode which uses client password to authenticate may be used in the access token request\n toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations\n (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details.\n* NOTE 3: The following values that were included up to version 3.4.1 of the present document have been removed: \"BASIC\" (to signal the use of the basic HTTP authentication) has been removed because it is insecure.\n \"TLS_CERT\" to signal an alternative non-token based authorization method using TLS certificates has been\n removed because the method is no longer supported.\n* NOTE 4: The client certificate is established by means outside the scope of the present document.\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values (see note 3): * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use\n an OAuth 2.0 token, obtained using the client\n credentials grant type after authenticating\n using client identifier and client password\n towards the token endpoint.\n* OAUTH2_CLIENT_CERT: In every HTTP request to the notification endpoint, use an\n OAuth 2.0 token, obtained using the client\n credentials grant type after mutually\n authenticating using client identifier and X.509\n certificates towards the token endpoint.\n","type":"array","items":{"type":"string","enum":["OAUTH2_CLIENT_CREDENTIALS","OAUTH2_CLIENT_CERT"]}},"paramsOauth2ClientCert":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CERT.\nShall be present if authType is \"OAUTH2_CLIENT_CERT\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\n","type":"object","required":["clientId","certificateRef","tokenEndpoint"],"properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint.\n","type":"string"},"certificateRef":{"description":"Fingerprint of the client certificate. The hash function shall use SHA256 or higher. See note 4.\n","type":"string","required":["type","value"],"properties":{"type":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"value":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS.\nShall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\nSee note 2.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"clientPassword":{"description":"Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualThreshold.Patch.422":{"description":"422 Unprocessable Content\n\nShall be returned upon the following error: The content type of the message content is supported\nand the message content of a request contains syntactically correct data but the data cannot be processed.\nThe general cause for this error and its handling is specified in clause 6.4 of ETSI GS NFV-SOL 013 ,\nincluding rules for the presence of the response body.\nSpecifically in case of this resource, the response code 422 shall also be returned if the VNFM has tested\nthe Notification endpoint as described in clause 6.4.9.3.2 and the test has failed.\nIn this case, the \"detail\" attribute in the \"ProblemDetails\" structure shall convey more information\nabout the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}} diff --git a/v5.3.1/SOL002-VNFPerformanceManagement-API.yaml b/v5.3.1/SOL002-VNFPerformanceManagement-API.yaml new file mode 100644 index 00000000..7e17913a --- /dev/null +++ b/v5.3.1/SOL002-VNFPerformanceManagement-API.yaml @@ -0,0 +1,17033 @@ +openapi: 3.0.2 +info: + title: SOL002 - VNF Perfomance Management interface + description: | + SOL002 - VNF Performance Management interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '2.13.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 002 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/05.03.01_60/gs_NFV-SOL002v050301p.pdf +servers: + - url: 'http://127.0.0.1/vnfpm/v2' + - url: 'https://127.0.0.1/vnfpm/v2' +paths: + /api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /pm_jobs: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The API consumer can use this method to retrieve information about PM + jobs. See clause 6.4.2.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + - $ref: '#/components/parameters/filter_pm_jobs' + - name: all_fields + description: > + Include all complex attributes in the response. See clause 5.3 of + ETSI GS NFV-SOL 013 [6] for details. The VNFM shall support this + parameter. + in: query + required: false + schema: + type: string + - name: fields + description: > + Complex attributes to be included into the response. See clause 5.3 + of ETSI GS NFV-SOL 013 [6] for details. The VNFM should support this + parameter. + in: query + required: false + schema: + type: string + - name: exclude_fields + description: > + Complex attributes to be excluded from the response. See clause 5.3 + of ETSI GS NFV-SOL 013 [6] for details. The VNFM should support this + parameter. + in: query + required: false + schema: + type: string + - $ref: '#/components/parameters/exclude_default_pm_jobs' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [6] for this + resource. + in: query + required: false + schema: + type: string + responses: + '200': + $ref: '#/components/responses/PmJobs.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: | + The POST method creates a PM job. See clause 6.4.2.3.1. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/PmJobCreationRequest' + responses: + '201': + $ref: '#/components/responses/PmJobs.Post.201' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/PmJobs.Post.422' + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/pm_jobs/{pmJobId}': + parameters: + - $ref: '#/components/parameters/PmJobId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The API consumer can use this method for reading an individual PM job. + See clause 6.4.3.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualPmJob.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: | + This method terminates an individual PM job. See clause 6.4.3.3.5. + responses: + '204': + $ref: '#/components/responses/IndividualPmJob.Delete.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method allows to modify an "individual PM job" resource. See clause + 6.4.3.3.4. + parameters: + - name: If-Unmodified-Since + description: > + Used to make the request method conditional on the selected + resource representation's last modification date being earlier than + or equal to the date provided in the field-value. If the condition + is not met, the request fails with a "412 Precondition Failed" + response. + required: false + in: header + schema: + type: string + format: date-time + - name: If-Match + description: > + Used to make the request method conditional on the recipient origin + server either having at least one current representation of the + target resource, when the field-value is "*", or having a current + representation of the target resource that has an entity-tag + matching a member of the list of entity-tags provided in the + field-value. If the condition is not met, the request fails with a + "412 Precondition Failed" response. + required: false + in: header + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/PmJobModificationRequest' + responses: + '200': + $ref: '#/components/responses/IndividualPmJob.Patch.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 409 CONFLICT + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 412 PRECONDITION FAILED + + Error: A precondition given in an HTTP request header is not + fulfilled. Typically, this is due to an ETag mismatch, indicating + that the resource was modified by another entity. The response body + should contain a ProblemDetails structure, in which the "detail" + attribute should convey more information about the error. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/IndividualPmJob.Patch.422' + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/pm_jobs/{pmJobId}/reports/{reportId}': + parameters: + - $ref: '#/components/parameters/PmJobId' + - $ref: '#/components/parameters/ReportId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The API consumer can use this method for reading an individual + performance report. See clause 6.4.4.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualPmJobReport.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /thresholds: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The API cosumer can use this method to query information about + thresholds. See clause 6.4.5.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - $ref: '#/components/parameters/filter_thresholds' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [6] for this + resource. + in: query + required: false + schema: + type: string + responses: + '200': + $ref: '#/components/responses/Thresholds.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + The POST method can be used by API consumer to create a threshold. See + clause 6.4.5.3.1. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/ThresholdCreationRequest' + responses: + '201': + $ref: '#/components/responses/Thresholds.Post.201' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/Thresholds.Post.422' + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/thresholds/{thresholdId}': + parameters: + - $ref: '#/components/parameters/ThresholdId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The client can use this method for reading an individual threshold. See + clause 6.4.6.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualThreshold.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: | + This method allows to delete a threshold. See clause 6.4.6.3.5. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + responses: + '204': + $ref: '#/components/responses/IndividualThreshold.Delete.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method allows to modify an "Individual threshold" resource. See + clause 6.4.6.3.4. + parameters: + - name: If-Unmodified-Since + description: > + Used to make the request method conditional on the selected + resource representation's last modification date being earlier than + or equal to the date provided in the field-value. If the condition + is not met, the request fails with a "412 Precondition Failed" + response. + required: false + in: header + schema: + type: string + format: date-time + - name: If-Match + description: > + Used to make the request method conditional on the recipient origin + server either having at least one current representation of the + target resource, when the field-value is "*", or having a current + representation of the target resource that has an entity-tag + matching a member of the list of entity-tags provided in the + field-value. If the condition is not met, the request fails with a + "412 Precondition Failed" response. + required: false + in: header + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/ThresholdModificationRequest' + responses: + '200': + $ref: '#/components/responses/IndividualThreshold.Patch.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 409 CONFLICT + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 412 PRECONDITION FAILED + + Error: A precondition given in an HTTP request header is not + fulfilled. Typically, this is due to an ETag mismatch, indicating + that the resource was modified by another entity. The response body + should contain a ProblemDetails structure, in which the "detail" + attribute should convey more information about the error. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/IndividualThreshold.Patch.422' + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + parameters: + filter_thresholds: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013. The VNFM shall support receiving this parameter as part of + the URI query string. The API consumer may supply this parameter. All + attribute names that appear in the Thresholds data type and in data + types referenced from it shall be supported by the VNFM in the filter + expression. + in: query + required: false + schema: + type: string + exclude_default_pm_jobs: + name: exclude_default + in: query + description: > + Indicates to exclude the following complex attributes from the response. + See clause 5.3 of ETSI GS NFV-SOL 013 for details. The VNFM shall + support this parameter. The following attributes shall be excluded from + the PmJob structure in the response body if this parameter is provided, + or none of the parameters "all_fields", "fields", "exclude_fields", + "exclude_default" are provided: + - reports + required: false + schema: + type: string + filter_pm_jobs: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013. The VNFM shall support receiving this parameter as part of + the URI query string. The API consumer may supply this parameter. All + attribute names that appear in the PmJob and in data types referenced + from it shall be supported by the VNFM in the filter expression. + in: query + required: false + schema: + type: string + PmJobId: + name: pmJobId + in: path + description: > + Identifier of the PM job. This identifier can be retrieved from the + resource referenced by the "Location" HTTP + + header in the response to a POST request creating a new PM job resource. + It can also be retrieved from the "id" + + attribute in the message content of that response. + required: true + style: simple + explode: false + schema: + type: string + ReportId: + name: reportId + in: path + description: | + Identifier of the performance report. + required: true + style: simple + explode: false + schema: + type: string + ThresholdId: + name: thresholdId + in: path + description: > + Identifier of the threshold. This identifier can be retrieved from the + resource referenced by the "Location" + + HTTP header in the response to a POST request creating a new threshold + resource. It can also be retrieved from + + the "id" attribute in the message content of that response. + required: true + style: simple + explode: false + schema: + type: string + requestBodies: + PmJobCreationRequest: + description: The VNF creation parameters + content: + application/json: + schema: + description: | + This type represents a request to create a PM job. + type: object + required: + - objectType + - objectInstanceIds + - criteria + - callbackUri + properties: + objectType: + description: > + Type of the measured object. The applicable measured object + type for a measurement is defined in clause 7.2 of ETSI GS + NFV-IFA 027. + type: string + objectInstanceIds: + description: > + Identifiers of the measured object instances for which + performance information is requested to be collected. + type: array + items: + description: | + An identifier with the intention of being globally unique. + type: string + subObjectInstanceIds: + description: > + Identifiers of the sub-object instances of the measured object + instance for which performance information is requested to be + collected. May be present if a sub-object is defined in clause + 6.2 of ETSI GS NFV-IFA 027for the related measured object + type. If this attribute is present, the cardinality of the + "objectInstanceIds" attribute shall be 1. If this attribute is + absent and a sub-object is defined in clause 6.2 of ETSI GS + NFV IFA 027 for the related measured object type, measurements + will be taken for all sub-object instances of the measured + object instance. + type: array + items: + description: > + An identifier that is unique for the respective type within + a VNF instance, but may not be globally unique. + type: string + criteria: + description: "This type represents collection criteria for PM jobs.\nNOTE 1:\tAt the end of each reportingPeriod, the API producer will inform the API consumer about availability of the \n performance data collected for each completed collection period during this reportingPeriod. \n The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance \n data for the collection periods within one reporting period are reported together.\nNOTE 2:\tIn particular when choosing short collection and reporting periods, the number of PM jobs that can be supported \n depends on the capability of the producing entity.\n" + type: object + required: + - collectionPeriod + - reportingPeriod + properties: + performanceMetric: + description: > + This defines the types of performance metrics for the + specified object instances. Valid values are specified as + "Measurement Name" values in clause 7.2 of ETSI GS NFV-IFA + 027. At least one of the two attributes (performance + metric or group) shall be present. + type: array + items: + type: string + performanceMetricGroup: + description: > + Group of performance metrics. A metric group is a + pre-defined list of metrics, known to the API producer + that it can decompose to individual metrics. Valid values + are specified as "Measurement Group" values in clause 7.2 + of ETSI GS NFV-IFA 027. At least one of the two attributes + (performance metric or group) shall be present. + type: array + items: + type: string + collectionPeriod: + description: > + SSpecifies the periodicity at which the API producer will + collect performance information. The unit shall be + seconds. See notes 1 and 2. + type: integer + minimum: 0 + maximum: 1024 + reportingPeriod: + description: > + Specifies the periodicity at which the API producer will + report to the API consumer about performance information. + The unit shall be seconds. See notes 1 and 2. + type: integer + minimum: 0 + maximum: 1024 + reportingBoundary: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + authentication: + description: > + * NOTE 1 : The clientId and clientPassword passed in a + subscription shall not be the same as the clientId and + clientPassword that are used to obtain authorization for API requests. Client credentials may differ between + subscriptions. The value of clientPassword should be generated by a random process. + * NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT + which uses mutual authentication based on X.509 + certificates, this mode which uses client password to authenticate may be used in the access token request + toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations + (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details. + * NOTE 3: The following values that were included up to + version 3.4.1 of the present document have been removed: + "BASIC" (to signal the use of the basic HTTP authentication) has been removed because it is insecure. + "TLS_CERT" to signal an alternative non-token based authorization method using TLS certificates has been + removed because the method is no longer supported. + * NOTE 4: The client certificate is established by means + outside the scope of the present document. + type: object + required: + - authType + properties: + authType: + description: > + Defines the types of Authentication / Authorization which + the API consumer is willing to accept when receiving a + notification. Permitted values (see note 3): * + OAUTH2_CLIENT_CREDENTIALS: In every + HTTP request to the notification endpoint, use + an OAuth 2.0 token, obtained using the client + credentials grant type after authenticating + using client identifier and client password + towards the token endpoint. + * OAUTH2_CLIENT_CERT: In every HTTP + request to the notification endpoint, use an + OAuth 2.0 token, obtained using the client + credentials grant type after mutually + authenticating using client identifier and X.509 + certificates towards the token endpoint. + type: array + items: + type: string + enum: + - OAUTH2_CLIENT_CREDENTIALS + - OAUTH2_CLIENT_CERT + paramsOauth2ClientCert: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CERT. + + Shall be present if authType is "OAUTH2_CLIENT_CERT" and + the contained information has not been provisioned out of + band. + + Shall be absent otherwise. + type: object + required: + - clientId + - certificateRef + - tokenEndpoint + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. + type: string + certificateRef: + description: > + Fingerprint of the client certificate. The hash + function shall use SHA256 or higher. See note 4. + type: string + required: + - type + - value + properties: + type: + description: | + A string defined in IETF RFC 8259. + type: string + value: + description: | + A string defined in IETF RFC 8259. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + paramsOauth2ClientCredentials: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CREDENTIALS. + + Shall be present if authType is + "OAUTH2_CLIENT_CREDENTIALS" and the contained information + has not been provisioned out of band. + + Shall be absent otherwise. + + See note 2. + type: object + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. Shall be present if it has not been + provisioned out of band. See note 1. + type: string + clientPassword: + description: > + Client password to be used in the access token request + of the OAuth 2.0 client credentials grant type. Shall + be present if it has not been provisioned out of band. + See note 1. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + PmJobModificationRequest: + description: Parameters for the PM job modification + content: + application/merge-patch+json: + schema: + description: "This type represents modifications to a PM job.\nNOTE:\tAt least one of the attributes defined in this type shall be present in request bodies.\n" + type: object + oneOf: + - required: + - callbackUri + - required: + - authentication + properties: + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + authentication: + description: > + * NOTE 1 : The clientId and clientPassword passed in a + subscription shall not be the same as the clientId and + clientPassword that are used to obtain authorization for API requests. Client credentials may differ between + subscriptions. The value of clientPassword should be generated by a random process. + * NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT + which uses mutual authentication based on X.509 + certificates, this mode which uses client password to authenticate may be used in the access token request + toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations + (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details. + * NOTE 3: The following values that were included up to + version 3.4.1 of the present document have been removed: + "BASIC" (to signal the use of the basic HTTP authentication) has been removed because it is insecure. + "TLS_CERT" to signal an alternative non-token based authorization method using TLS certificates has been + removed because the method is no longer supported. + * NOTE 4: The client certificate is established by means + outside the scope of the present document. + type: object + required: + - authType + properties: + authType: + description: > + Defines the types of Authentication / Authorization which + the API consumer is willing to accept when receiving a + notification. Permitted values (see note 3): * + OAUTH2_CLIENT_CREDENTIALS: In every + HTTP request to the notification endpoint, use + an OAuth 2.0 token, obtained using the client + credentials grant type after authenticating + using client identifier and client password + towards the token endpoint. + * OAUTH2_CLIENT_CERT: In every HTTP + request to the notification endpoint, use an + OAuth 2.0 token, obtained using the client + credentials grant type after mutually + authenticating using client identifier and X.509 + certificates towards the token endpoint. + type: array + items: + type: string + enum: + - OAUTH2_CLIENT_CREDENTIALS + - OAUTH2_CLIENT_CERT + paramsOauth2ClientCert: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CERT. + + Shall be present if authType is "OAUTH2_CLIENT_CERT" and + the contained information has not been provisioned out of + band. + + Shall be absent otherwise. + type: object + required: + - clientId + - certificateRef + - tokenEndpoint + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. + type: string + certificateRef: + description: > + Fingerprint of the client certificate. The hash + function shall use SHA256 or higher. See note 4. + type: string + required: + - type + - value + properties: + type: + description: | + A string defined in IETF RFC 8259. + type: string + value: + description: | + A string defined in IETF RFC 8259. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + paramsOauth2ClientCredentials: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CREDENTIALS. + + Shall be present if authType is + "OAUTH2_CLIENT_CREDENTIALS" and the contained information + has not been provisioned out of band. + + Shall be absent otherwise. + + See note 2. + type: object + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. Shall be present if it has not been + provisioned out of band. See note 1. + type: string + clientPassword: + description: > + Client password to be used in the access token request + of the OAuth 2.0 client credentials grant type. Shall + be present if it has not been provisioned out of band. + See note 1. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + ThresholdCreationRequest: + description: | + Request parameters to create a new "Individual threshold" resource. + content: + application/json: + schema: + description: | + This type represents a request to create a threshold. + type: object + required: + - objectType + - objectInstanceId + - criteria + - callbackUri + properties: + objectType: + description: > + Type of the measured object. The applicable measured object + type for a measurement is defined in clause 7.2 of ETSI GS + NFV-IFA 027. + type: string + objectInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + subObjectInstanceIds: + description: > + Identifiers of the sub-object instances of the measured object + instance associated with this threshold. May be present if a + sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for + the related measured object type. If this attribute is absent + and a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA + 027 for the measured object type, measurements will be taken + for all sub-object instances of the measured object instance. + type: array + items: + description: > + An identifier that is unique for the respective type within + a VNF instance, but may not be globally unique. + type: string + criteria: + description: "This type represents criteria that define a threshold.\nNOTE 1:\tIn the present document, simple thresholds are defined. The definition of additional threshold types is left for \n future specification.\nNOTE 2:\tThe hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create \n a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or \n reject the request). \n" + type: object + required: + - performanceMetric + - thresholdType + properties: + performanceMetric: + description: > + Defines the performance metric associated with the + threshold. Valid values are specified as "Measurement + Name" values in clause 7.2 of ETSI GS NFV-IFA 027. + type: string + thresholdType: + description: "Type of threshold. This attribute determines which other attributes are present in the data structure.\nPermitted values: -\tSIMPLE: Single-valued static threshold. See note 1.\n" + type: string + enum: + - SIMPLE + simpleThresholdDetails: + description: > + Details of a simple threshold. Shall be present if + thresholdType="SIMPLE". + type: object + required: + - thresholdValue + - hysteresis + properties: + thresholdValue: + description: > + The threshold value. Shall be represented as a + floating point number. + type: number + format: float + hysteresis: + description: > + The hysteresis of the threshold. Shall be represented + as a non-negative floating point number. + + A notification with crossing direction "UP" will be + generated if the measured value reaches or exceeds + "thresholdValue" + "hysteresis". A notification with + crossing direction "DOWN" will be generated if the + measured value reaches or undercuts "thresholdValue" - + "hysteresis". See note 2. + type: number + minimum: 0 + maximum: 1024 + format: float + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + authentication: + description: > + * NOTE 1 : The clientId and clientPassword passed in a + subscription shall not be the same as the clientId and + clientPassword that are used to obtain authorization for API requests. Client credentials may differ between + subscriptions. The value of clientPassword should be generated by a random process. + * NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT + which uses mutual authentication based on X.509 + certificates, this mode which uses client password to authenticate may be used in the access token request + toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations + (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details. + * NOTE 3: The following values that were included up to + version 3.4.1 of the present document have been removed: + "BASIC" (to signal the use of the basic HTTP authentication) has been removed because it is insecure. + "TLS_CERT" to signal an alternative non-token based authorization method using TLS certificates has been + removed because the method is no longer supported. + * NOTE 4: The client certificate is established by means + outside the scope of the present document. + type: object + required: + - authType + properties: + authType: + description: > + Defines the types of Authentication / Authorization which + the API consumer is willing to accept when receiving a + notification. Permitted values (see note 3): * + OAUTH2_CLIENT_CREDENTIALS: In every + HTTP request to the notification endpoint, use + an OAuth 2.0 token, obtained using the client + credentials grant type after authenticating + using client identifier and client password + towards the token endpoint. + * OAUTH2_CLIENT_CERT: In every HTTP + request to the notification endpoint, use an + OAuth 2.0 token, obtained using the client + credentials grant type after mutually + authenticating using client identifier and X.509 + certificates towards the token endpoint. + type: array + items: + type: string + enum: + - OAUTH2_CLIENT_CREDENTIALS + - OAUTH2_CLIENT_CERT + paramsOauth2ClientCert: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CERT. + + Shall be present if authType is "OAUTH2_CLIENT_CERT" and + the contained information has not been provisioned out of + band. + + Shall be absent otherwise. + type: object + required: + - clientId + - certificateRef + - tokenEndpoint + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. + type: string + certificateRef: + description: > + Fingerprint of the client certificate. The hash + function shall use SHA256 or higher. See note 4. + type: string + required: + - type + - value + properties: + type: + description: | + A string defined in IETF RFC 8259. + type: string + value: + description: | + A string defined in IETF RFC 8259. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + paramsOauth2ClientCredentials: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CREDENTIALS. + + Shall be present if authType is + "OAUTH2_CLIENT_CREDENTIALS" and the contained information + has not been provisioned out of band. + + Shall be absent otherwise. + + See note 2. + type: object + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. Shall be present if it has not been + provisioned out of band. See note 1. + type: string + clientPassword: + description: > + Client password to be used in the access token request + of the OAuth 2.0 client credentials grant type. Shall + be present if it has not been provisioned out of band. + See note 1. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + ThresholdModificationRequest: + description: Parameters for the threshold modification. + content: + application/merge-patch+json: + schema: + description: "This type represents modifications to a threshold.\nNOTE:\tAt least one of the attributes defined in this type shall be present in request bodies.\n" + type: object + oneOf: + - required: + - callbackUri + - required: + - authentication + properties: + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + authentication: + description: > + * NOTE 1 : The clientId and clientPassword passed in a + subscription shall not be the same as the clientId and + clientPassword that are used to obtain authorization for API requests. Client credentials may differ between + subscriptions. The value of clientPassword should be generated by a random process. + * NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT + which uses mutual authentication based on X.509 + certificates, this mode which uses client password to authenticate may be used in the access token request + toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations + (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details. + * NOTE 3: The following values that were included up to + version 3.4.1 of the present document have been removed: + "BASIC" (to signal the use of the basic HTTP authentication) has been removed because it is insecure. + "TLS_CERT" to signal an alternative non-token based authorization method using TLS certificates has been + removed because the method is no longer supported. + * NOTE 4: The client certificate is established by means + outside the scope of the present document. + type: object + required: + - authType + properties: + authType: + description: > + Defines the types of Authentication / Authorization which + the API consumer is willing to accept when receiving a + notification. Permitted values (see note 3): * + OAUTH2_CLIENT_CREDENTIALS: In every + HTTP request to the notification endpoint, use + an OAuth 2.0 token, obtained using the client + credentials grant type after authenticating + using client identifier and client password + towards the token endpoint. + * OAUTH2_CLIENT_CERT: In every HTTP + request to the notification endpoint, use an + OAuth 2.0 token, obtained using the client + credentials grant type after mutually + authenticating using client identifier and X.509 + certificates towards the token endpoint. + type: array + items: + type: string + enum: + - OAUTH2_CLIENT_CREDENTIALS + - OAUTH2_CLIENT_CERT + paramsOauth2ClientCert: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CERT. + + Shall be present if authType is "OAUTH2_CLIENT_CERT" and + the contained information has not been provisioned out of + band. + + Shall be absent otherwise. + type: object + required: + - clientId + - certificateRef + - tokenEndpoint + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. + type: string + certificateRef: + description: > + Fingerprint of the client certificate. The hash + function shall use SHA256 or higher. See note 4. + type: string + required: + - type + - value + properties: + type: + description: | + A string defined in IETF RFC 8259. + type: string + value: + description: | + A string defined in IETF RFC 8259. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + paramsOauth2ClientCredentials: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CREDENTIALS. + + Shall be present if authType is + "OAUTH2_CLIENT_CREDENTIALS" and the contained information + has not been provisioned out of band. + + Shall be absent otherwise. + + See note 2. + type: object + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. Shall be present if it has not been + provisioned out of band. See note 1. + type: string + clientPassword: + description: > + Client password to be used in the access token request + of the OAuth 2.0 client credentials grant type. Shall + be present if it has not been provisioned out of band. + See note 1. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + responses: + PmJobs.Get.200: + description: > + 200 OK + + Shall be returned when information about zero or more PM jobs was + queried successfully. The response body + + shall contain in an array the representations of zero or more PM jobs, + as defined in clause 6.5.2.7. + + If the "filter" URI parameter or one of the "all_fields", "fields" (if + supported), "exclude_fields" + + (if supported) or "exclude_default" URI parameters was supplied in the + request, the data in the response + + body shall have been transformed according to the rules specified in + clauses 5.2.2 and 5.3.2 of + + ETSI GS NFV-SOL 013, respectively. If the VNFM supports alternative 2 + (paging) according to clause 5.4.2.1 + + of ETSI GS NFV-SOL 013for this resource, inclusion of the Link HTTP + header in this response shall follow + + the provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: | + This type represents a PM job. + type: object + required: + - id + - objectType + - objectInstanceIds + - criteria + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + objectType: + description: > + Type of the measured object. The applicable measured object + type for a measurement is defined in clause 7.2 of ETSI GS + NFV-IFA 027. + type: string + objectInstanceIds: + description: > + Identifiers of the VNF instances for which performance + information is collected. + type: array + items: + description: | + An identifier with the intention of being globally unique. + type: string + subObjectInstanceIds: + description: > + Identifiers of the sub-object instances of the measured + object instance for which performance information is + requested to be collected. May be present if a sub-object is + defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related + measured object type. If this attribute is present, the + cardinality of the "objectInstanceIds" attribute shall be 1. + If this attribute is absent and a sub-object is defined in + clause 6.2 of ETSI GS NFV IFA 027 for the related measured + object type, measurements will be taken for all sub-object + instances of the measured object instance. + type: array + items: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + criteria: + description: "This type represents collection criteria for PM jobs.\nNOTE 1:\tAt the end of each reportingPeriod, the API producer will inform the API consumer about availability of the \n performance data collected for each completed collection period during this reportingPeriod. \n The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance \n data for the collection periods within one reporting period are reported together.\nNOTE 2:\tIn particular when choosing short collection and reporting periods, the number of PM jobs that can be supported \n depends on the capability of the producing entity.\n" + type: object + required: + - collectionPeriod + - reportingPeriod + properties: + performanceMetric: + description: > + This defines the types of performance metrics for the + specified object instances. Valid values are specified + as "Measurement Name" values in clause 7.2 of ETSI GS + NFV-IFA 027. At least one of the two attributes + (performance metric or group) shall be present. + type: array + items: + type: string + performanceMetricGroup: + description: > + Group of performance metrics. A metric group is a + pre-defined list of metrics, known to the API producer + that it can decompose to individual metrics. Valid + values are specified as "Measurement Group" values in + clause 7.2 of ETSI GS NFV-IFA 027. At least one of the + two attributes (performance metric or group) shall be + present. + type: array + items: + type: string + collectionPeriod: + description: > + SSpecifies the periodicity at which the API producer + will collect performance information. The unit shall be + seconds. See notes 1 and 2. + type: integer + minimum: 0 + maximum: 1024 + reportingPeriod: + description: > + Specifies the periodicity at which the API producer will + report to the API consumer about performance + information. The unit shall be seconds. See notes 1 and + 2. + type: integer + minimum: 0 + maximum: 1024 + reportingBoundary: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + reports: + description: > + Information about available reports collected by this PM + job. + type: object + required: + - href + - readyTime + properties: + href: + description: | + The URI where the report can be obtained. + type: string + format: url + readyTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + expiryTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + fileSize: + description: | + The size of the report file in bytes, if known. + type: integer + minimum: 0 + pmJobConnection: + description: > + An access information and interface information of PM job to + monitor the PM of VNF instance by the VNFM. This can + include for instance certain interface endpoint URI together + with necessary credentials to access it. + type: array + items: + description: "The MonitoringConnection shall follow the indications. * NOTE:\tThe VNFM can be made aware of monitoring connection information, including their identifiers to \n be used by configuration means outside the scope of the present document (e.g. using relevant NFV-MANO management \n APIs as defined in ETSI GS NFV-SOL 009). \n" + type: object + required: + - id + - monitoringType + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + monitoringType: + description: "Type of monitoring way. VALUES: \n •\tVIM_CISM\n •\tEXTERNAL\n •\tPAAS\n" + type: string + enum: + - VIM_CISM + - EXTERNAL + - PAAS + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being globally + unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: | + A string defined in IETF RFC 8259. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + objects: + description: > + Links to resources representing the measure object + instances for which performance information is + collected. Shall be present if the measured object + instance information is accessible as a resource. + type: array + items: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + PmJobs.Post.201: + description: > + 201 CREATED + + Shall be returned when the PM job has been created successfully. The + response body shall contain a + + representation of the created PM job resource. The HTTP response shall + include a "Location" HTTP header that + + points to the created "Individual PM job" resource. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: The resource URI of the created PM Job + style: simple + explode: false + schema: + type: string + format: url + content: + application/json: + schema: + description: | + This type represents a PM job. + type: object + required: + - id + - objectType + - objectInstanceIds + - criteria + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + objectType: + description: > + Type of the measured object. The applicable measured object + type for a measurement is defined in clause 7.2 of ETSI GS + NFV-IFA 027. + type: string + objectInstanceIds: + description: > + Identifiers of the VNF instances for which performance + information is collected. + type: array + items: + description: | + An identifier with the intention of being globally unique. + type: string + subObjectInstanceIds: + description: > + Identifiers of the sub-object instances of the measured object + instance for which performance information is requested to be + collected. May be present if a sub-object is defined in clause + 6.2 of ETSI GS NFV-IFA 027 for the related measured object + type. If this attribute is present, the cardinality of the + "objectInstanceIds" attribute shall be 1. If this attribute is + absent and a sub-object is defined in clause 6.2 of ETSI GS + NFV IFA 027 for the related measured object type, measurements + will be taken for all sub-object instances of the measured + object instance. + type: array + items: + description: > + An identifier that is unique for the respective type within + a VNF instance, but may not be globally unique. + type: string + criteria: + description: "This type represents collection criteria for PM jobs.\nNOTE 1:\tAt the end of each reportingPeriod, the API producer will inform the API consumer about availability of the \n performance data collected for each completed collection period during this reportingPeriod. \n The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance \n data for the collection periods within one reporting period are reported together.\nNOTE 2:\tIn particular when choosing short collection and reporting periods, the number of PM jobs that can be supported \n depends on the capability of the producing entity.\n" + type: object + required: + - collectionPeriod + - reportingPeriod + properties: + performanceMetric: + description: > + This defines the types of performance metrics for the + specified object instances. Valid values are specified as + "Measurement Name" values in clause 7.2 of ETSI GS NFV-IFA + 027. At least one of the two attributes (performance + metric or group) shall be present. + type: array + items: + type: string + performanceMetricGroup: + description: > + Group of performance metrics. A metric group is a + pre-defined list of metrics, known to the API producer + that it can decompose to individual metrics. Valid values + are specified as "Measurement Group" values in clause 7.2 + of ETSI GS NFV-IFA 027. At least one of the two attributes + (performance metric or group) shall be present. + type: array + items: + type: string + collectionPeriod: + description: > + SSpecifies the periodicity at which the API producer will + collect performance information. The unit shall be + seconds. See notes 1 and 2. + type: integer + minimum: 0 + maximum: 1024 + reportingPeriod: + description: > + Specifies the periodicity at which the API producer will + report to the API consumer about performance information. + The unit shall be seconds. See notes 1 and 2. + type: integer + minimum: 0 + maximum: 1024 + reportingBoundary: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + reports: + description: | + Information about available reports collected by this PM job. + type: object + required: + - href + - readyTime + properties: + href: + description: | + The URI where the report can be obtained. + type: string + format: url + readyTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + expiryTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + fileSize: + description: | + The size of the report file in bytes, if known. + type: integer + minimum: 0 + pmJobConnection: + description: > + An access information and interface information of PM job to + monitor the PM of VNF instance by the VNFM. This can include + for instance certain interface endpoint URI together with + necessary credentials to access it. + type: array + items: + description: "The MonitoringConnection shall follow the indications. * NOTE:\tThe VNFM can be made aware of monitoring connection information, including their identifiers to \n be used by configuration means outside the scope of the present document (e.g. using relevant NFV-MANO management \n APIs as defined in ETSI GS NFV-SOL 009). \n" + type: object + required: + - id + - monitoringType + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + monitoringType: + description: "Type of monitoring way. VALUES: \n •\tVIM_CISM\n •\tEXTERNAL\n •\tPAAS\n" + type: string + enum: + - VIM_CISM + - EXTERNAL + - PAAS + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being globally + unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: | + A string defined in IETF RFC 8259. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + objects: + description: > + Links to resources representing the measure object + instances for which performance information is collected. + Shall be present if the measured object instance + information is accessible as a resource. + type: array + items: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + PmJobs.Post.422: + description: > + 422 Unprocessable Content + + + Shall be returned upon the following error: The content type of the + message content is supported + + and the message content of a request contains syntactically correct data + but the data cannot be + + processed. + + The general cause for this error and its handling is specified in clause + 6.4 of ETSI GS NFV-SOL 013, + + including rules for the presence of the response body. + + Specifically in case of this resource, the response code 422 shall also + be returned if the VNFM has + + tested the Notification endpoint as described in clause 6.4.9.3.2 and + the test has failed. + + In this case, the "detail" attribute in the "ProblemDetails" structure + shall convey more + + information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: Version of the API used in the response. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualPmJob.Get.200: + description: > + 200 OK + + Shall be returned when information about an individual PM job has been + ueried successfully. The response + + body shall contain a representation of the "Individual PM job" resource. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + ETag: + description: > + Used to provide the current entity-tag for the selected resource + representation. It can be sent in "200 OK", "201 Created" and "204 + No Content" responses. + style: simple + schema: + type: string + Last-Modified: + description: > + Used to provide a timestamp indicating the date and time at which + the server believes the selected resource representation was last + modified. It can be sent in "200 OK", "201 Created" and "204 No + Content" responses. + style: simple + schema: + type: string + format: date-time + content: + application/json: + schema: + description: | + This type represents a PM job. + type: object + required: + - id + - objectType + - objectInstanceIds + - criteria + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + objectType: + description: > + Type of the measured object. The applicable measured object + type for a measurement is defined in clause 7.2 of ETSI GS + NFV-IFA 027. + type: string + objectInstanceIds: + description: > + Identifiers of the VNF instances for which performance + information is collected. + type: array + items: + description: | + An identifier with the intention of being globally unique. + type: string + subObjectInstanceIds: + description: > + Identifiers of the sub-object instances of the measured object + instance for which performance information is requested to be + collected. May be present if a sub-object is defined in clause + 6.2 of ETSI GS NFV-IFA 027 for the related measured object + type. If this attribute is present, the cardinality of the + "objectInstanceIds" attribute shall be 1. If this attribute is + absent and a sub-object is defined in clause 6.2 of ETSI GS + NFV IFA 027 for the related measured object type, measurements + will be taken for all sub-object instances of the measured + object instance. + type: array + items: + description: > + An identifier that is unique for the respective type within + a VNF instance, but may not be globally unique. + type: string + criteria: + description: "This type represents collection criteria for PM jobs.\nNOTE 1:\tAt the end of each reportingPeriod, the API producer will inform the API consumer about availability of the \n performance data collected for each completed collection period during this reportingPeriod. \n The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance \n data for the collection periods within one reporting period are reported together.\nNOTE 2:\tIn particular when choosing short collection and reporting periods, the number of PM jobs that can be supported \n depends on the capability of the producing entity.\n" + type: object + required: + - collectionPeriod + - reportingPeriod + properties: + performanceMetric: + description: > + This defines the types of performance metrics for the + specified object instances. Valid values are specified as + "Measurement Name" values in clause 7.2 of ETSI GS NFV-IFA + 027. At least one of the two attributes (performance + metric or group) shall be present. + type: array + items: + type: string + performanceMetricGroup: + description: > + Group of performance metrics. A metric group is a + pre-defined list of metrics, known to the API producer + that it can decompose to individual metrics. Valid values + are specified as "Measurement Group" values in clause 7.2 + of ETSI GS NFV-IFA 027. At least one of the two attributes + (performance metric or group) shall be present. + type: array + items: + type: string + collectionPeriod: + description: > + SSpecifies the periodicity at which the API producer will + collect performance information. The unit shall be + seconds. See notes 1 and 2. + type: integer + minimum: 0 + maximum: 1024 + reportingPeriod: + description: > + Specifies the periodicity at which the API producer will + report to the API consumer about performance information. + The unit shall be seconds. See notes 1 and 2. + type: integer + minimum: 0 + maximum: 1024 + reportingBoundary: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + reports: + description: | + Information about available reports collected by this PM job. + type: object + required: + - href + - readyTime + properties: + href: + description: | + The URI where the report can be obtained. + type: string + format: url + readyTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + expiryTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + fileSize: + description: | + The size of the report file in bytes, if known. + type: integer + minimum: 0 + pmJobConnection: + description: > + An access information and interface information of PM job to + monitor the PM of VNF instance by the VNFM. This can include + for instance certain interface endpoint URI together with + necessary credentials to access it. + type: array + items: + description: "The MonitoringConnection shall follow the indications. * NOTE:\tThe VNFM can be made aware of monitoring connection information, including their identifiers to \n be used by configuration means outside the scope of the present document (e.g. using relevant NFV-MANO management \n APIs as defined in ETSI GS NFV-SOL 009). \n" + type: object + required: + - id + - monitoringType + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + monitoringType: + description: "Type of monitoring way. VALUES: \n •\tVIM_CISM\n •\tEXTERNAL\n •\tPAAS\n" + type: string + enum: + - VIM_CISM + - EXTERNAL + - PAAS + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being globally + unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: | + A string defined in IETF RFC 8259. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + objects: + description: > + Links to resources representing the measure object + instances for which performance information is collected. + Shall be present if the measured object instance + information is accessible as a resource. + type: array + items: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualPmJob.Delete.204: + description: > + 204 NO CONTENT + + Shall be returned when the PM job has been deleted successfully. The + response body shall be empty. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: {} + IndividualPmJob.Patch.200: + description: > + 200 OK + + Shall be returned when the request has been processed successfully. The + response body shall contain a data + + structure of type "PmJobModifications". + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + ETag: + description: > + Used to provide the current entity-tag for the selected resource + representation. It can be sent in "200 OK", "201 Created" and "204 + No Content" responses. + style: simple + schema: + type: string + Last-Modified: + description: > + Used to provide a timestamp indicating the date and time at which + the server believes the selected resource representation was last + modified. It can be sent in "200 OK", "201 Created" and "204 No + Content" responses. + style: simple + schema: + type: string + format: date-time + content: + application/json: + schema: + description: "This type represents modifications to a PM job.\nNOTE:\tAt least one of the attributes defined in this type shall be present in request bodies.\n" + type: object + oneOf: + - required: + - callbackUri + - required: + - authentication + properties: + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + authentication: + description: > + * NOTE 1 : The clientId and clientPassword passed in a + subscription shall not be the same as the clientId and + clientPassword that are used to obtain authorization for API requests. Client credentials may differ between + subscriptions. The value of clientPassword should be generated by a random process. + * NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT + which uses mutual authentication based on X.509 + certificates, this mode which uses client password to authenticate may be used in the access token request + toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations + (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details. + * NOTE 3: The following values that were included up to + version 3.4.1 of the present document have been removed: + "BASIC" (to signal the use of the basic HTTP authentication) has been removed because it is insecure. + "TLS_CERT" to signal an alternative non-token based authorization method using TLS certificates has been + removed because the method is no longer supported. + * NOTE 4: The client certificate is established by means + outside the scope of the present document. + type: object + required: + - authType + properties: + authType: + description: > + Defines the types of Authentication / Authorization which + the API consumer is willing to accept when receiving a + notification. Permitted values (see note 3): * + OAUTH2_CLIENT_CREDENTIALS: In every + HTTP request to the notification endpoint, use + an OAuth 2.0 token, obtained using the client + credentials grant type after authenticating + using client identifier and client password + towards the token endpoint. + * OAUTH2_CLIENT_CERT: In every HTTP + request to the notification endpoint, use an + OAuth 2.0 token, obtained using the client + credentials grant type after mutually + authenticating using client identifier and X.509 + certificates towards the token endpoint. + type: array + items: + type: string + enum: + - OAUTH2_CLIENT_CREDENTIALS + - OAUTH2_CLIENT_CERT + paramsOauth2ClientCert: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CERT. + + Shall be present if authType is "OAUTH2_CLIENT_CERT" and + the contained information has not been provisioned out of + band. + + Shall be absent otherwise. + type: object + required: + - clientId + - certificateRef + - tokenEndpoint + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. + type: string + certificateRef: + description: > + Fingerprint of the client certificate. The hash + function shall use SHA256 or higher. See note 4. + type: string + required: + - type + - value + properties: + type: + description: | + A string defined in IETF RFC 8259. + type: string + value: + description: | + A string defined in IETF RFC 8259. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + paramsOauth2ClientCredentials: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CREDENTIALS. + + Shall be present if authType is + "OAUTH2_CLIENT_CREDENTIALS" and the contained information + has not been provisioned out of band. + + Shall be absent otherwise. + + See note 2. + type: object + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. Shall be present if it has not been + provisioned out of band. See note 1. + type: string + clientPassword: + description: > + Client password to be used in the access token request + of the OAuth 2.0 client credentials grant type. Shall + be present if it has not been provisioned out of band. + See note 1. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualPmJob.Patch.422: + description: > + 422 Unprocessable Content + + + Shall be returned upon the following error: The content type of the + message content is supported + + and the message content of a request contains syntactically correct data + but the data cannot be processed. + + The general cause for this error and its handling is specified in clause + 6.4 of ETSI GS NFV-SOL 013, + + including rules for the presence of the response body. + + Specifically in case of this resource, the response code 422 shall also + be returned if the VNFM has tested + + the Notification endpoint as described in clause 6.4.9.3.2 and the test + has failed. + + In this case, the "detail" attribute in the "ProblemDetails" structure + shall convey more information + + about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: Version of the API used in the response. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualPmJobReport.Get.200: + description: > + 200 OK + + Shall be returned when information of an individual performance report + has been read successfully. + + The response body shall contain a representation of the "Individual + performance report" resource. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: "This type defines the format of a performance report provided by the VNFM to the NFVO as a result of collecting performance information as part of a PM job.\nNOTE:\tThe sub-object allows to structure the measured object but is not to be confused with sub-counters which allow \n to structure the measurement value.\n\nEXAMPLE:\n Measured object: VnfInstanceXYZ\n Sub-object: VnfcInstance1\n Measurement: vCPU_utilization\n Sub-counters: vCPU utilization of each of the vCPUs of VnfcInstance1 (vCPU utilization.vCPU1, vCPU_utilization.vCPU2, etc.).\n" + type: object + required: + - entries + properties: + entries: + description: > + List of performance information entries. Each performance + report entry is for a given metric of a given object (i.e. VNF + instance), but can include multiple collected values. + type: array + items: + type: object + required: + - objectType + - objectInstanceId + - performanceMetric + - performanceValue + properties: + objectType: + description: > + Type of the measured object. The applicable measured + object type for a measurement is defined in clause 7.2 + of ETSI GS NFV-IFA 027. + type: string + objectInstanceId: + description: > + An identifier with the intention of being globally + unique. + type: string + subObjectInstanceId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + performanceMetric: + description: > + Name of the metric collected. This attribute shall + contain the related "Measurement Name" value as defined + in clause 7.2 of ETSI GS NFV-IFA 027. + type: string + performanceValues: + description: | + List of performance values with associated timestamp. + type: array + items: + type: object + required: + - timeStamp + - value + properties: + timeStamp: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + value: + description: > + Value of the metric collected. The type of this + attribute shall correspond to the related + "Measurement Unit" as defined in clause 7.2. of + ETSI GS NFV-IFA 027. + type: object + context: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + Thresholds.Get.200: + description: > + 200 OK + + Information about zero or more thresholds was queried successfully. + + If the "filter" URI parameter was supplied in the request, the data in + the response body shall have + + been transformed according to the rules specified in clause 5.2.2 of + ETSI GS NFV SOL 013. + + The response body shall contain in an array the representations of zero + or more thresholds, + + as defined in clause 6.5.2.9. If the VNFM supports alternative 2 + (paging) according to clause 5.4.2.1 + + of ETSI GS NFV-SOL 013 for this resource, inclusion of the Link HTTP + header in this response shall + + follow the provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: | + This type represents a threshold. + type: object + required: + - id + - objectType + - objectInstanceId + - criteria + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + objectType: + description: > + Type of the measured object. The applicable measured object + type for a measurement is defined in clause 7.2 of ETSI GS + NFV-IFA 027. + type: string + objectInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + subObjectInstanceIds: + description: > + Identifiers of the sub-object instances of the measured + object instance associated with the threshold. May be + present if a sub-object is defined in clause 6.2 of ETSI GS + NFV-IFA 027 for the related measurement type. If this + attribute is absent and a sub-object is defined in clause + 6.2 of ETSI GS NFV-IFA 027 for the related measured object + type, measurements will be taken for all sub-object + instances of the measured object instance. + type: array + items: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + criteria: + description: "This type represents criteria that define a threshold.\nNOTE 1:\tIn the present document, simple thresholds are defined. The definition of additional threshold types is left for \n future specification.\nNOTE 2:\tThe hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create \n a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or \n reject the request). \n" + type: object + required: + - performanceMetric + - thresholdType + properties: + performanceMetric: + description: > + Defines the performance metric associated with the + threshold. Valid values are specified as "Measurement + Name" values in clause 7.2 of ETSI GS NFV-IFA 027. + type: string + thresholdType: + description: "Type of threshold. This attribute determines which other attributes are present in the data structure.\nPermitted values: -\tSIMPLE: Single-valued static threshold. See note 1.\n" + type: string + enum: + - SIMPLE + simpleThresholdDetails: + description: > + Details of a simple threshold. Shall be present if + thresholdType="SIMPLE". + type: object + required: + - thresholdValue + - hysteresis + properties: + thresholdValue: + description: > + The threshold value. Shall be represented as a + floating point number. + type: number + format: float + hysteresis: + description: > + The hysteresis of the threshold. Shall be + represented as a non-negative floating point number. + + A notification with crossing direction "UP" will be + generated if the measured value reaches or exceeds + "thresholdValue" + "hysteresis". A notification with + crossing direction "DOWN" will be generated if the + measured value reaches or undercuts "thresholdValue" + - "hysteresis". See note 2. + type: number + minimum: 0 + maximum: 1024 + format: float + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + object: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + Thresholds.Post.201: + description: > + 201 CREATED + + Shall be returned when a threshold has been created successfully. The + response body shall contain a + + representation of the created "Individual threshold" resource. The HTTP + response shall include a + + "Location" HTTP header that contains the resource URI of the created + resource. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: The resource URI of the created threshold + style: simple + explode: false + schema: + type: string + format: url + content: + application/json: + schema: + description: | + This type represents a threshold. + type: object + required: + - id + - objectType + - objectInstanceId + - criteria + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + objectType: + description: > + Type of the measured object. The applicable measured object + type for a measurement is defined in clause 7.2 of ETSI GS + NFV-IFA 027. + type: string + objectInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + subObjectInstanceIds: + description: > + Identifiers of the sub-object instances of the measured object + instance associated with the threshold. May be present if a + sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for + the related measurement type. If this attribute is absent and + a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 + for the related measured object type, measurements will be + taken for all sub-object instances of the measured object + instance. + type: array + items: + description: > + An identifier that is unique for the respective type within + a VNF instance, but may not be globally unique. + type: string + criteria: + description: "This type represents criteria that define a threshold.\nNOTE 1:\tIn the present document, simple thresholds are defined. The definition of additional threshold types is left for \n future specification.\nNOTE 2:\tThe hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create \n a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or \n reject the request). \n" + type: object + required: + - performanceMetric + - thresholdType + properties: + performanceMetric: + description: > + Defines the performance metric associated with the + threshold. Valid values are specified as "Measurement + Name" values in clause 7.2 of ETSI GS NFV-IFA 027. + type: string + thresholdType: + description: "Type of threshold. This attribute determines which other attributes are present in the data structure.\nPermitted values: -\tSIMPLE: Single-valued static threshold. See note 1.\n" + type: string + enum: + - SIMPLE + simpleThresholdDetails: + description: > + Details of a simple threshold. Shall be present if + thresholdType="SIMPLE". + type: object + required: + - thresholdValue + - hysteresis + properties: + thresholdValue: + description: > + The threshold value. Shall be represented as a + floating point number. + type: number + format: float + hysteresis: + description: > + The hysteresis of the threshold. Shall be represented + as a non-negative floating point number. + + A notification with crossing direction "UP" will be + generated if the measured value reaches or exceeds + "thresholdValue" + "hysteresis". A notification with + crossing direction "DOWN" will be generated if the + measured value reaches or undercuts "thresholdValue" - + "hysteresis". See note 2. + type: number + minimum: 0 + maximum: 1024 + format: float + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + object: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + Thresholds.Post.422: + description: > + 422 Unprocessable Content + + + Shall be returned upon the following error: The content type of the + message content is supported + + and the message content of a request contains syntactically correct data + but the data cannot be processed. + + The general cause for this error and its handling is specified in clause + 6.4 of ETSI GS NFV-SOL 013, + + including rules for the presence of the response body. + + Specifically in case of this resource, the response code 422 shall also + be returned if the VNFM has tested + + the Notification endpoint as described in clause 6.4.9.3.2 and the test + has failed. + + In this case, the "detail" attribute in the "ProblemDetails" structure + shall convey more information + + about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: Version of the API used in the response. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualThreshold.Get.200: + description: > + 200 OK + + Shall be returned when information about an individual threshold has + been queried successfully. + + The response body shall contain a representation of the threshold. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + ETag: + description: > + Used to provide the current entity-tag for the selected resource + representation. It can be sent in "200 OK", "201 Created" and "204 + No Content" responses. + style: simple + schema: + type: string + Last-Modified: + description: > + Used to provide a timestamp indicating the date and time at which + the server believes the selected resource representation was last + modified. It can be sent in "200 OK", "201 Created" and "204 No + Content" responses. + style: simple + schema: + type: string + format: date-time + content: + application/json: + schema: + description: | + This type represents a threshold. + type: object + required: + - id + - objectType + - objectInstanceId + - criteria + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + objectType: + description: > + Type of the measured object. The applicable measured object + type for a measurement is defined in clause 7.2 of ETSI GS + NFV-IFA 027. + type: string + objectInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + subObjectInstanceIds: + description: > + Identifiers of the sub-object instances of the measured object + instance associated with the threshold. May be present if a + sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for + the related measurement type. If this attribute is absent and + a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 + for the related measured object type, measurements will be + taken for all sub-object instances of the measured object + instance. + type: array + items: + description: > + An identifier that is unique for the respective type within + a VNF instance, but may not be globally unique. + type: string + criteria: + description: "This type represents criteria that define a threshold.\nNOTE 1:\tIn the present document, simple thresholds are defined. The definition of additional threshold types is left for \n future specification.\nNOTE 2:\tThe hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create \n a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or \n reject the request). \n" + type: object + required: + - performanceMetric + - thresholdType + properties: + performanceMetric: + description: > + Defines the performance metric associated with the + threshold. Valid values are specified as "Measurement + Name" values in clause 7.2 of ETSI GS NFV-IFA 027. + type: string + thresholdType: + description: "Type of threshold. This attribute determines which other attributes are present in the data structure.\nPermitted values: -\tSIMPLE: Single-valued static threshold. See note 1.\n" + type: string + enum: + - SIMPLE + simpleThresholdDetails: + description: > + Details of a simple threshold. Shall be present if + thresholdType="SIMPLE". + type: object + required: + - thresholdValue + - hysteresis + properties: + thresholdValue: + description: > + The threshold value. Shall be represented as a + floating point number. + type: number + format: float + hysteresis: + description: > + The hysteresis of the threshold. Shall be represented + as a non-negative floating point number. + + A notification with crossing direction "UP" will be + generated if the measured value reaches or exceeds + "thresholdValue" + "hysteresis". A notification with + crossing direction "DOWN" will be generated if the + measured value reaches or undercuts "thresholdValue" - + "hysteresis". See note 2. + type: number + minimum: 0 + maximum: 1024 + format: float + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + object: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualThreshold.Delete.204: + description: > + 204 NO CONTENT + + Shall be returned when the threshold was deleted successfully. The + response body shall be empty. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + content: {} + IndividualThreshold.Patch.200: + description: > + 200 OK + + Shall be returned when the request has been processed successfully. The + response body shall contain a data + + structure of type "ThresholdModifications". + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + ETag: + description: > + Used to provide the current entity-tag for the selected resource + representation. It can be sent in "200 OK", "201 Created" and "204 + No Content" responses. + style: simple + schema: + type: string + Last-Modified: + description: > + Used to provide a timestamp indicating the date and time at which + the server believes the selected resource representation was last + modified. It can be sent in "200 OK", "201 Created" and "204 No + Content" responses. + style: simple + schema: + type: string + format: date-time + content: + application/json: + schema: + description: "This type represents modifications to a threshold.\nNOTE:\tAt least one of the attributes defined in this type shall be present in request bodies.\n" + type: object + oneOf: + - required: + - callbackUri + - required: + - authentication + properties: + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + authentication: + description: > + * NOTE 1 : The clientId and clientPassword passed in a + subscription shall not be the same as the clientId and + clientPassword that are used to obtain authorization for API requests. Client credentials may differ between + subscriptions. The value of clientPassword should be generated by a random process. + * NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT + which uses mutual authentication based on X.509 + certificates, this mode which uses client password to authenticate may be used in the access token request + toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations + (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details. + * NOTE 3: The following values that were included up to + version 3.4.1 of the present document have been removed: + "BASIC" (to signal the use of the basic HTTP authentication) has been removed because it is insecure. + "TLS_CERT" to signal an alternative non-token based authorization method using TLS certificates has been + removed because the method is no longer supported. + * NOTE 4: The client certificate is established by means + outside the scope of the present document. + type: object + required: + - authType + properties: + authType: + description: > + Defines the types of Authentication / Authorization which + the API consumer is willing to accept when receiving a + notification. Permitted values (see note 3): * + OAUTH2_CLIENT_CREDENTIALS: In every + HTTP request to the notification endpoint, use + an OAuth 2.0 token, obtained using the client + credentials grant type after authenticating + using client identifier and client password + towards the token endpoint. + * OAUTH2_CLIENT_CERT: In every HTTP + request to the notification endpoint, use an + OAuth 2.0 token, obtained using the client + credentials grant type after mutually + authenticating using client identifier and X.509 + certificates towards the token endpoint. + type: array + items: + type: string + enum: + - OAUTH2_CLIENT_CREDENTIALS + - OAUTH2_CLIENT_CERT + paramsOauth2ClientCert: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CERT. + + Shall be present if authType is "OAUTH2_CLIENT_CERT" and + the contained information has not been provisioned out of + band. + + Shall be absent otherwise. + type: object + required: + - clientId + - certificateRef + - tokenEndpoint + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. + type: string + certificateRef: + description: > + Fingerprint of the client certificate. The hash + function shall use SHA256 or higher. See note 4. + type: string + required: + - type + - value + properties: + type: + description: | + A string defined in IETF RFC 8259. + type: string + value: + description: | + A string defined in IETF RFC 8259. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + paramsOauth2ClientCredentials: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CREDENTIALS. + + Shall be present if authType is + "OAUTH2_CLIENT_CREDENTIALS" and the contained information + has not been provisioned out of band. + + Shall be absent otherwise. + + See note 2. + type: object + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. Shall be present if it has not been + provisioned out of band. See note 1. + type: string + clientPassword: + description: > + Client password to be used in the access token request + of the OAuth 2.0 client credentials grant type. Shall + be present if it has not been provisioned out of band. + See note 1. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualThreshold.Patch.422: + description: > + 422 Unprocessable Content + + + Shall be returned upon the following error: The content type of the + message content is supported + + and the message content of a request contains syntactically correct data + but the data cannot be processed. + + The general cause for this error and its handling is specified in clause + 6.4 of ETSI GS NFV-SOL 013 , + + including rules for the presence of the response body. + + Specifically in case of this resource, the response code 422 shall also + be returned if the VNFM has tested + + the Notification endpoint as described in clause 6.4.9.3.2 and the test + has failed. + + In this case, the "detail" attribute in the "ProblemDetails" structure + shall convey more information + + about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: Version of the API used in the response. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + diff --git a/v5.3.1/SOL002-VNFPerformanceManagementNotification-API.json b/v5.3.1/SOL002-VNFPerformanceManagementNotification-API.json new file mode 100644 index 00000000..373a37d9 --- /dev/null +++ b/v5.3.1/SOL002-VNFPerformanceManagementNotification-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL002 - VNF Performance Management Notification interface","description":"SOL002 - VNF Performance Management Notification interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"2.13.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 002 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/05.03.01_60/gs_NFV-SOL002v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/callback/v2"},{"url":"https://127.0.0.1/callback/v2"}],"paths":{"/URI_is_provided_by_the_client_when_creating_the_subscription-PerformanceInformationAvailableNotification":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method allows the server to test the notification endpoint that is provided by the client,\ne.g. during subscription. See clause 6.4.9.3.2.\n","responses":{"204":{"$ref":"#/components/responses/VNFPMNotification.Get.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"The POST method delivers a notification regarding a performance management event from API producer to an API\nconsumer. See clause 6.4.9.3.1.\n","parameters":[{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/PerformanceInformationAvailableNotification"},"responses":{"204":{"$ref":"#/components/responses/VNFPMNotification.Post.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/URI_is_provided_by_the_client_when_creating_the_subscription-ThresholdCrossedNotification":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method allows the server to test the notification endpoint that is provided by the client,\ne.g. during subscription. See clause 6.4.9.3.2.\n","responses":{"204":{"$ref":"#/components/responses/VNFPMNotification.Get.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"The POST method delivers a notification regarding a performance management event from API producer to an API\nconsumer. See clause 6.4.9.3.1.\n","parameters":[{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/ThresholdCrossedNotification"},"responses":{"204":{"$ref":"#/components/responses/VNFPMNotification.Post.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"requestBodies":{"PerformanceInformationAvailableNotification":{"description":"Notification about performance information availability.\n","content":{"application/json":{"schema":{"description":"This notification informs the receiver that performance information is available. The notification shall be triggered by the VNFM when new performance information collected by a PM job is available. The periodicity of triggering this notification is influenced by the \"reportingPeriod\" attribute in the \"PmJobCriteria\" data structure.\n","type":"object","required":["id","notificationType","timeStamp","pmJobId","objectType","objectInstanceId","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"PerformanceInformationAvailableNotification\" for this notification type.\n","type":"string","enum":["PerformanceInformationAvailableNotification"]},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"pmJobId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance for which the measurements have been taken. Shall be present if the related PM job has been set up to measure only a subset of all sub-object instances of the measured object instance and a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type. Shall be absent otherwise.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"_links":{"description":"Links to resources related to this notification.\n","type":"object","required":["pmJob","performanceReport"],"properties":{"objectInstance":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"pmJob":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"performanceReport":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true},"ThresholdCrossedNotification":{"description":"Notification about crossed threshold.\n","content":{"application/json":{"schema":{"description":"This type represents a notification that is sent when a threshold has been crossed.\nNOTE:\tThe timing of sending this notification is determined by the capability of the \n producing entity to evaluate the threshold crossing condition.\n \nThe notification shall be triggered by the VNFM when a threshold has been crossed.\nNOTE:\tThe sub-object allows to structure the measured object, but is not to be confused \n with sub-counters which allow to structure the measurement.\n","type":"object","required":["id","notificationType","timeStamp","thresholdId","crossingDirection","objectType","objectInstanceId","performanceMetric","performanceValue","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"ThresholdCrossedNotification\" for this notification type.\n","type":"string","enum":["ThresholdCrossedNotification"]},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"thresholdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"crossingDirection":{"type":"string","enum":["UP","DOWN"]},"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"performanceMetric":{"description":"Performance metric associated with the threshold. This attribute shall contain the related \"Measurement Name\" value as defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"performanceValue":{"description":"Value of the metric that resulted in threshold crossing. The type of this attribute shall correspond to the related \"Measurement Unit\" as defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"object"},"context":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this notification.\n","type":"object","required":["threshold"],"properties":{"objectInstance":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"threshold":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true}},"responses":{"VNFPMNotification.Get.204":{"description":"204 NO CONTENT\nShall be returned to indicate the notification endpoint has been tested successfully. The response body\nshall be empty.\n","headers":{"Version":{"description":"Version of the API used in the response.\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{}},"VNFPMNotification.Post.204":{"description":"204 NO CONTENT\nShall be returned when the notification has been delivered successfully. The response body shall be empty.\n","headers":{"Version":{"description":"Version of the API used in the response.\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{}}}}} diff --git a/v5.3.1/SOL002-VNFPerformanceManagementNotification-API.yaml b/v5.3.1/SOL002-VNFPerformanceManagementNotification-API.yaml new file mode 100644 index 00000000..ac0645d8 --- /dev/null +++ b/v5.3.1/SOL002-VNFPerformanceManagementNotification-API.yaml @@ -0,0 +1,3128 @@ +openapi: 3.0.2 +info: + title: SOL002 - VNF Performance Management Notification interface + description: | + SOL002 - VNF Performance Management Notification interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '2.13.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 002 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/05.03.01_60/gs_NFV-SOL002v050301p.pdf +servers: + - url: 'http://127.0.0.1/callback/v2' + - url: 'https://127.0.0.1/callback/v2' +paths: + /URI_is_provided_by_the_client_when_creating_the_subscription-PerformanceInformationAvailableNotification: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The GET method allows the server to test the notification endpoint that + is provided by the client, + + e.g. during subscription. See clause 6.4.9.3.2. + responses: + '204': + $ref: '#/components/responses/VNFPMNotification.Get.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + The POST method delivers a notification regarding a performance + management event from API producer to an API + + consumer. See clause 6.4.9.3.1. + parameters: + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/PerformanceInformationAvailableNotification' + responses: + '204': + $ref: '#/components/responses/VNFPMNotification.Post.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /URI_is_provided_by_the_client_when_creating_the_subscription-ThresholdCrossedNotification: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The GET method allows the server to test the notification endpoint that + is provided by the client, + + e.g. during subscription. See clause 6.4.9.3.2. + responses: + '204': + $ref: '#/components/responses/VNFPMNotification.Get.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + The POST method delivers a notification regarding a performance + management event from API producer to an API + + consumer. See clause 6.4.9.3.1. + parameters: + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/ThresholdCrossedNotification' + responses: + '204': + $ref: '#/components/responses/VNFPMNotification.Post.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + requestBodies: + PerformanceInformationAvailableNotification: + description: | + Notification about performance information availability. + content: + application/json: + schema: + description: > + This notification informs the receiver that performance + information is available. The notification shall be triggered by + the VNFM when new performance information collected by a PM job is + available. The periodicity of triggering this notification is + influenced by the "reportingPeriod" attribute in the + "PmJobCriteria" data structure. + type: object + required: + - id + - notificationType + - timeStamp + - pmJobId + - objectType + - objectInstanceId + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall be + set to "PerformanceInformationAvailableNotification" for this + notification type. + type: string + enum: + - PerformanceInformationAvailableNotification + timeStamp: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + pmJobId: + description: | + An identifier with the intention of being globally unique. + type: string + objectType: + description: > + Type of the measured object. The applicable measured object + type for a measurement is defined in clause 7.2 of ETSI GS + NFV-IFA 027. + type: string + objectInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + subObjectInstanceIds: + description: > + Identifiers of the sub-object instances of the measured object + instance for which the measurements have been taken. Shall be + present if the related PM job has been set up to measure only + a subset of all sub-object instances of the measured object + instance and a sub-object is defined in clause 6.2 of ETSI GS + NFV-IFA 027 for the related measured object type. Shall be + absent otherwise. + type: array + items: + description: > + An identifier that is unique for the respective type within + a VNF instance, but may not be globally unique. + type: string + _links: + description: | + Links to resources related to this notification. + type: object + required: + - pmJob + - performanceReport + properties: + objectInstance: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + pmJob: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + performanceReport: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + ThresholdCrossedNotification: + description: | + Notification about crossed threshold. + content: + application/json: + schema: + description: "This type represents a notification that is sent when a threshold has been crossed.\nNOTE:\tThe timing of sending this notification is determined by the capability of the \n producing entity to evaluate the threshold crossing condition.\n \nThe notification shall be triggered by the VNFM when a threshold has been crossed.\nNOTE:\tThe sub-object allows to structure the measured object, but is not to be confused \n with sub-counters which allow to structure the measurement.\n" + type: object + required: + - id + - notificationType + - timeStamp + - thresholdId + - crossingDirection + - objectType + - objectInstanceId + - performanceMetric + - performanceValue + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall be + set to "ThresholdCrossedNotification" for this notification + type. + type: string + enum: + - ThresholdCrossedNotification + timeStamp: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + thresholdId: + description: | + An identifier with the intention of being globally unique. + type: string + crossingDirection: + type: string + enum: + - UP + - DOWN + objectType: + description: > + Type of the measured object. The applicable measured object + type for a measurement is defined in clause 7.2 of ETSI GS + NFV-IFA 027. + type: string + objectInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + subObjectInstanceId: + description: > + An identifier that is unique for the respective type within a + VNF instance, but may not be globally unique. + type: string + performanceMetric: + description: > + Performance metric associated with the threshold. This + attribute shall contain the related "Measurement Name" value + as defined in clause 7.2 of ETSI GS NFV-IFA 027. + type: string + performanceValue: + description: > + Value of the metric that resulted in threshold crossing. The + type of this attribute shall correspond to the related + "Measurement Unit" as defined in clause 7.2 of ETSI GS NFV-IFA + 027. + type: object + context: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + _links: + description: | + Links to resources related to this notification. + type: object + required: + - threshold + properties: + objectInstance: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + threshold: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + responses: + VNFPMNotification.Get.204: + description: > + 204 NO CONTENT + + Shall be returned to indicate the notification endpoint has been tested + successfully. The response body + + shall be empty. + headers: + Version: + description: | + Version of the API used in the response. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + content: {} + VNFPMNotification.Post.204: + description: > + 204 NO CONTENT + + Shall be returned when the notification has been delivered successfully. + The response body shall be empty. + headers: + Version: + description: | + Version of the API used in the response. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + content: {} + diff --git a/v5.3.1/SOL003-APIVersion-API.json b/v5.3.1/SOL003-APIVersion-API.json new file mode 100644 index 00000000..6dd18a80 --- /dev/null +++ b/v5.3.1/SOL003-APIVersion-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL003 - API version interface","description":"SOL003 - API version Interface\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.\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"1.0.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 003 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf"},"paths":{"/vrqan/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnffm/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnfind/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnflcm/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnfpm/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/grant/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnfpkgm/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnfsnapshotpkgm/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}}} diff --git a/v5.3.1/SOL003-APIVersion-API.yaml b/v5.3.1/SOL003-APIVersion-API.yaml new file mode 100644 index 00000000..c66bc465 --- /dev/null +++ b/v5.3.1/SOL003-APIVersion-API.yaml @@ -0,0 +1,13743 @@ +openapi: 3.0.2 +info: + title: SOL003 - API version interface + description: > + SOL003 - API version Interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '1.0.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 003 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf +paths: + /vrqan/api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /vnffm/api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /vnfind/api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /vnflcm/api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /vnfpm/api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /grant/api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /vnfpkgm/api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /vnfsnapshotpkgm/api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + diff --git a/v5.3.1/SOL003-VNFFaultManagement-API.json b/v5.3.1/SOL003-VNFFaultManagement-API.json new file mode 100644 index 00000000..e561aeb1 --- /dev/null +++ b/v5.3.1/SOL003-VNFFaultManagement-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL003 - VNF Fault Management interface","description":"SOL003 - VNF Fault Management interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"1.14.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 003 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/vnffm/v1"},{"url":"https://127.0.0.1/vnffm/v1"}],"paths":{"/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/alarms":{"get":{"description":"The API consumer can use this method to retrieve information about the alarm list. See clause 7.4.2.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}},{"$ref":"#/components/parameters/filter_alarm_list"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/Alarms.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/alarms/{alarmId}":{"parameters":[{"$ref":"#/components/parameters/AlarmId"},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"get":{"description":"The API consumer can use this method to read an individual alarm. See clause 7.4.3.3.2.\n","responses":{"200":{"$ref":"#/components/responses/IndividualAlarm.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method modifies an \"Individual alarm\" resource. See clause 7.4.3.3.4.\n","parameters":[{"name":"If-Unmodified-Since","description":"Used to make the request method conditional on the selected resource representation's last modification date being earlier than or equal to the date provided in the field-value. If the condition is not met, the request fails with a \"412 Precondition Failed\" response.\n","required":false,"in":"header","schema":{"type":"string","format":"date-time"}},{"name":"If-Match","description":"Used to make the request method conditional on the recipient origin server either having at least one current representation of the target resource, when the field-value is \"*\", or having a current representation of the target resource that has an entity-tag matching a member of the list of entity-tags provided in the field-value. If the condition is not met, the request fails with a \"412 Precondition Failed\" response.\n","required":false,"in":"header","schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/IndividualAlarmRequest"},"responses":{"200":{"$ref":"#/components/responses/IndividualAlarm.Patch.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/IndividualAlarm.Patch.409"},"412":{"$ref":"#/components/responses/IndividualAlarm.Patch.412"},"422":{"description":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/subscriptions":{"parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"post":{"description":"The POST method creates a new subscription. See clause 7.4.4.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/FmSubscriptionRequest"},"responses":{"201":{"$ref":"#/components/responses/Subscriptions.Post.200"},"303":{"$ref":"#/components/responses/Subscriptions.Post.303"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/Subscriptions.Post.422"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"get":{"description":"The API consumer can use this method to retrieve the list of active subscriptions for VNF alarms subscribed\nby the API consumer. It can be used e.g. for resynchronization after error situations. See clause 7.4.4.3.2.\n","parameters":[{"$ref":"#/components/parameters/filter_subscriptions"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/Subscriptions.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/subscriptions/{subscriptionId}":{"parameters":[{"$ref":"#/components/parameters/SubscriptionId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The API consumer can use this method for reading an individual subscription for VNF\nalarms subscribed by the API consumer. See clause 7.4.5.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualSubscription.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method terminates an individual subscription. See clause 7.4.5.3.5.\n","responses":{"204":{"$ref":"#/components/responses/IndividualSubscription.Delete.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"parameters":{"filter_alarm_list":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part of the URI query string. The NFVO may supply this parameter. The following attribute names shall be supported by the VNFM in the attribute based filtering expression: id, managedObjectId, rootCauseFaultyResource/faultyResourceType, eventType, perceivedSeverity, probableCause.\n","in":"query","required":false,"schema":{"type":"string"}},"filter_subscriptions":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part of the URI query string. The NFVO may supply this parameter. All attribute names that appear in the FmSubscription and in data types referenced from it shall be supported by the VNFM in the filter expression.\n","in":"query","required":false,"schema":{"type":"string"}},"AlarmId":{"name":"alarmId","in":"path","description":"Identifier of the alarm.\nThis identifier can be retrieved from the \"id\" attribute of the \"alarm\" attribute in the AlarmNotification or\nAlarmClearedNotification. It can also be retrieved from the \"id\" attribute of the applicable array element in\nthe message content of the response to a GET request to the \"Alarms\" resource.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"SubscriptionId":{"name":"subscriptionId","in":"path","description":"Identifier of this subscription.\nThis identifier can be retrieved from the resource referenced by the\n\"Location\" HTTP header in the response to a POST request creating a\nnew \"Individual subscription\" resource. It can also be retrieved from the \"id\"\nattribute in the message content of that response.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}}},"requestBodies":{"IndividualAlarmRequest":{"description":"The VNF creation parameters","content":{"application/merge-patch+json":{"schema":{"description":"This type represents attribute modifications for an \"Individual alarm\" resource, i.e. modifications to a resource representation based on the \"Alarm\" data type. The attributes of \"Alarm\" that can be modified are included in the \"AlarmModifications\" data type.\n","type":"object","required":["ackState"],"properties":{"ackState":{"description":"New value of the \"ackState\" attribute in \"Alarm\". Permitted values: * ACKNOWLEDGED * UNACKNOWLEDGED\n","type":"string","enum":["ACKNOWLEDGED","UNACKNOWLEDGED"]}}}}},"required":true},"FmSubscriptionRequest":{"description":"The VNF creation parameters","content":{"application/json":{"schema":{"description":"This type represents a subscription request related to notifications about VNF faults.\n","type":"object","required":["callbackUri"],"properties":{"filter":{"description":"This type represents a subscription filter related to notifications about VNF faults.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdId"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tAlarmNotification -\tAlarmClearedNotification -\tAlarmListRebuiltNotification See note.\n","type":"array","items":{"type":"string","enum":["AlarmNotification","AlarmClearedNotification","AlarmListRebuiltNotification"]}},"faultyResourceTypes":{"description":"Match VNF alarms with a faulty resource type listed in this attribute.\n","type":"array","items":{"description":"The enumeration FaultyResourceType represents those types of faulty resource.\n","type":"string","enum":["COMPUTE","STORAGE","NETWORK"]}},"perceivedSeverities":{"description":"Match VNF alarms with a perceived severity listed in this attribute.\n","type":"array","items":{"description":"Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n","type":"string","enum":["CRITICAL","MAJOR","MINOR","WARNING","INDETERMINATE","CLEARED"]}},"eventTypes":{"description":"Match VNF alarms with an event type listed in this attribute.\n","type":"array","items":{"description":"The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment fault (ITU-T Recommendation X.733).\n","type":"string","enum":["COMMUNICATIONS_ALARM","PROCESSING_ERROR_ALARM","ENVIRONMENTAL_ALARM","QOS_ALARM","EQUIPMENT_ALARM"]}},"probableCauses":{"description":"Match VNF alarms with a probable cause listed in this attribute.\n","type":"array","items":{"type":"string"}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE 1 : The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between\n subscriptions. The value of clientPassword should be generated by a random process.\n* NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT which uses mutual authentication based on X.509 certificates, this mode which uses client password to authenticate may be used in the access token request\n toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations\n (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details.\n* NOTE 3: The following values that were included up to version 3.4.1 of the present document have been removed: \"BASIC\" (to signal the use of the basic HTTP authentication) has been removed because it is insecure.\n \"TLS_CERT\" to signal an alternative non-token based authorization method using TLS certificates has been\n removed because the method is no longer supported.\n* NOTE 4: The client certificate is established by means outside the scope of the present document.\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values (see note 3): * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use\n an OAuth 2.0 token, obtained using the client\n credentials grant type after authenticating\n using client identifier and client password\n towards the token endpoint.\n* OAUTH2_CLIENT_CERT: In every HTTP request to the notification endpoint, use an\n OAuth 2.0 token, obtained using the client\n credentials grant type after mutually\n authenticating using client identifier and X.509\n certificates towards the token endpoint.\n","type":"array","items":{"type":"string","enum":["OAUTH2_CLIENT_CREDENTIALS","OAUTH2_CLIENT_CERT"]}},"paramsOauth2ClientCert":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CERT.\nShall be present if authType is \"OAUTH2_CLIENT_CERT\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\n","type":"object","required":["clientId","certificateRef","tokenEndpoint"],"properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint.\n","type":"string"},"certificateRef":{"description":"Fingerprint of the client certificate. The hash function shall use SHA256 or higher. See note 4.\n","type":"string","required":["type","value"],"properties":{"type":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"value":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS.\nShall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\nSee note 2.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"clientPassword":{"description":"Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true}},"responses":{"Alarms.Get.200":{"description":"200 OK\n\nShall be returned when information about zero or more alarms has been queried successfully.\nThe response body shall contain in an array the representations of zero or more alarms as\ndefined in clause 7.5.2.4.\nIf the \"filter\" URI parameter was supplied in the request, the data in the response body\nshall have been transformed according to the rules specified in clause 5.2.2 of ETSI GS NFV-SOL 013.\nIf the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013\nfor this resource, inclusion of the Link HTTP header in this response shall follow the provisions\nin clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The alarm data type encapsulates information about an alarm.\nNOTE 1: For an alarm about upcoming impact due to NFVI operation and maintenance (i.e. the attribute \"faultType\" has the value \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE\"), the attribute \n \"rootCauseFaultyResource\" indicates a resource to be impacted. Further information on the upcoming\n impact (e.g. group of impacted resources, time of impact) is provided in the attribute \"faultDetails\".\nNOTE 2: When alarms are due to upcoming NFVI operation and maintenance (i.e. the attribute \"faultType\" has the value \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE\"), the attribute \"faultDetails\" shall include \n information about the anticipated time of the maintenance. See provisions under the present table.\n\nIf the attribute \"faultType\" has the value \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE\", the following provisions apply for the values of the attribute \"faultDetails\" related to changes in the state of virtualised resources: - One of the entries in the array shall provide information about the anticipated time of maintenance in the \n following format: \"anticipatedTime=$time\", wherein \"$time\" shall be formatted as a \"DateTime\", as specified \n in ETSI GS NFV-SOL 013 [8]. \n - One of the entries in the array shall provide identification information about the affinity/anti-affinity\n group defined in the VNFD that is associated to the affected virtualised resource indicated by \n \"rootCauseFaultyResource\" in the following format: \"affinityOrAntiAffinityGroupId=$group\", wherein \n \"$group\" shall be equal to the \"affinityOrAntiAffinityGroupId\" value in the corresponding \"VduProfile\" (for a \n VNFC/COMPUTE affected resource) or \"VirtualLinkProfile\" for a VL/NETWORK affected resource) in the \n VNFD, which is mapped by the VNFM to the virtualised resource group identifier in the virtualised resource \n change notification received by the VNFM from the VIM.\n","type":"object","required":["id","managedObjectId","alarmRaisedTime","ackState","perceivedSeverity","eventTime","eventType","probableCause","isRootCause","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"managedObjectId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"rootCauseFaultyResource":{"description":"This type represents the faulty virtual resources that have a negative impact on a VNF.\n","type":"object","required":["faultyResource","faultyResourceType"],"properties":{"faultyResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"faultyResourceType":{"description":"The enumeration FaultyResourceType represents those types of faulty resource.\n","type":"string","enum":["COMPUTE","STORAGE","NETWORK"]}}},"alarmRaisedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"alarmChangedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"alarmClearedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"alarmAcknowledgedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"ackState":{"description":"Acknowledgement state of the alarm. Permitted values: * UNACKNOWLEDGED * ACKNOWLEDGED.\n","type":"string","enum":["UNACKNOWLEDGED","ACKNOWLEDGED"]},"perceivedSeverity":{"description":"Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n","type":"string","enum":["CRITICAL","MAJOR","MINOR","WARNING","INDETERMINATE","CLEARED"]},"eventTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"eventType":{"description":"The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment fault (ITU-T Recommendation X.733).\n","type":"string","enum":["COMMUNICATIONS_ALARM","PROCESSING_ERROR_ALARM","ENVIRONMENTAL_ALARM","QOS_ALARM","EQUIPMENT_ALARM"]},"faultType":{"description":"Additional information to clarify the type of the fault. Valid values applicable to specific Alarms are specified as \"Alarm definition identifier\" values of the Alarm applicable to Or-Vnfm reference point, as defined in clause 7.3 of ETSI GS NFV-IFA 045 [13]. If the alarm is related to changes in the state of virtualised resources due to NFVI operation and maintenance, this attribute shall be set to \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE\".\n","type":"string"},"probableCause":{"description":"Information about the probable cause of the fault. Valid values applicable to specific Alarms are specified as \"Probable cause\" values of the Alarm applicable to Or-Vnfm reference point, as defined in clause 7.3 of ETSI GS NFV-IFA 045 [13]. If the attribute \"faultType\" has the value “NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE”, the permitted values are: - \"NFVI_COMPONENT_MAINTENANCE\": Maintenance of NFVI components, e.g. \n physical maintenance/repair, hypervisor software updates, etc.\n - \"NFVI_COMPONENT_EVACUATION\": Evacuation of physical hosts.\n - \"NFVI_COMPONENT_OPTIMIZATION\": Operation and management of NFVI resources, e.g.\n to support energy efficiency or resource usage.\n","type":"string"},"isRootCause":{"description":"Attribute indicating if this fault is the root for other correlated alarms. If true, then the alarms listed in the attribute \"correlatedAlarmIds\" are caused by this fault.\n","type":"boolean"},"correlatedAlarmIds":{"description":"List of identifiers of other alarms correlated to this fault.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"faultDetails":{"description":"Provides additional information about the fault. See notes 1 and 2. Valid values applicable to specific Alarms are specified as \"Fault details\" values of the Alarm applicable to Or-Vnfm reference point, as defined in clause 7.3 of ETSI GS NFV-IFA 045 [13].\n","type":"array","items":{"type":"string"}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"objectInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualAlarm.Get.200":{"description":"200 OK\n\nShall be returned when information about an individual alarm has been read successfully.\nThe response body shall contain a representation of the individual alarm\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"ETag":{"description":"Used to provide the current entity-tag for the selected resource representation. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string"}},"Last-Modified":{"description":"Used to provide a timestamp indicating the date and time at which the server believes the selected resource representation was last modified. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string","format":"date-time"}}},"content":{"application/json":{"schema":{"description":"The alarm data type encapsulates information about an alarm.\nNOTE 1: For an alarm about upcoming impact due to NFVI operation and maintenance (i.e. the attribute \"faultType\" has the value \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE\"), the attribute \n \"rootCauseFaultyResource\" indicates a resource to be impacted. Further information on the upcoming\n impact (e.g. group of impacted resources, time of impact) is provided in the attribute \"faultDetails\".\nNOTE 2: When alarms are due to upcoming NFVI operation and maintenance (i.e. the attribute \"faultType\" has the value \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE\"), the attribute \"faultDetails\" shall include \n information about the anticipated time of the maintenance. See provisions under the present table.\n\nIf the attribute \"faultType\" has the value \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE\", the following provisions apply for the values of the attribute \"faultDetails\" related to changes in the state of virtualised resources: - One of the entries in the array shall provide information about the anticipated time of maintenance in the \n following format: \"anticipatedTime=$time\", wherein \"$time\" shall be formatted as a \"DateTime\", as specified \n in ETSI GS NFV-SOL 013 [8]. \n - One of the entries in the array shall provide identification information about the affinity/anti-affinity\n group defined in the VNFD that is associated to the affected virtualised resource indicated by \n \"rootCauseFaultyResource\" in the following format: \"affinityOrAntiAffinityGroupId=$group\", wherein \n \"$group\" shall be equal to the \"affinityOrAntiAffinityGroupId\" value in the corresponding \"VduProfile\" (for a \n VNFC/COMPUTE affected resource) or \"VirtualLinkProfile\" for a VL/NETWORK affected resource) in the \n VNFD, which is mapped by the VNFM to the virtualised resource group identifier in the virtualised resource \n change notification received by the VNFM from the VIM.\n","type":"object","required":["id","managedObjectId","alarmRaisedTime","ackState","perceivedSeverity","eventTime","eventType","probableCause","isRootCause","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"managedObjectId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"rootCauseFaultyResource":{"description":"This type represents the faulty virtual resources that have a negative impact on a VNF.\n","type":"object","required":["faultyResource","faultyResourceType"],"properties":{"faultyResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"faultyResourceType":{"description":"The enumeration FaultyResourceType represents those types of faulty resource.\n","type":"string","enum":["COMPUTE","STORAGE","NETWORK"]}}},"alarmRaisedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"alarmChangedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"alarmClearedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"alarmAcknowledgedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"ackState":{"description":"Acknowledgement state of the alarm. Permitted values: * UNACKNOWLEDGED * ACKNOWLEDGED.\n","type":"string","enum":["UNACKNOWLEDGED","ACKNOWLEDGED"]},"perceivedSeverity":{"description":"Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n","type":"string","enum":["CRITICAL","MAJOR","MINOR","WARNING","INDETERMINATE","CLEARED"]},"eventTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"eventType":{"description":"The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment fault (ITU-T Recommendation X.733).\n","type":"string","enum":["COMMUNICATIONS_ALARM","PROCESSING_ERROR_ALARM","ENVIRONMENTAL_ALARM","QOS_ALARM","EQUIPMENT_ALARM"]},"faultType":{"description":"Additional information to clarify the type of the fault. Valid values applicable to specific Alarms are specified as \"Alarm definition identifier\" values of the Alarm applicable to Or-Vnfm reference point, as defined in clause 7.3 of ETSI GS NFV-IFA 045 [13]. If the alarm is related to changes in the state of virtualised resources due to NFVI operation and maintenance, this attribute shall be set to \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE\".\n","type":"string"},"probableCause":{"description":"Information about the probable cause of the fault. Valid values applicable to specific Alarms are specified as \"Probable cause\" values of the Alarm applicable to Or-Vnfm reference point, as defined in clause 7.3 of ETSI GS NFV-IFA 045 [13]. If the attribute \"faultType\" has the value “NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE”, the permitted values are: - \"NFVI_COMPONENT_MAINTENANCE\": Maintenance of NFVI components, e.g. \n physical maintenance/repair, hypervisor software updates, etc.\n - \"NFVI_COMPONENT_EVACUATION\": Evacuation of physical hosts.\n - \"NFVI_COMPONENT_OPTIMIZATION\": Operation and management of NFVI resources, e.g.\n to support energy efficiency or resource usage.\n","type":"string"},"isRootCause":{"description":"Attribute indicating if this fault is the root for other correlated alarms. If true, then the alarms listed in the attribute \"correlatedAlarmIds\" are caused by this fault.\n","type":"boolean"},"correlatedAlarmIds":{"description":"List of identifiers of other alarms correlated to this fault.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"faultDetails":{"description":"Provides additional information about the fault. See notes 1 and 2. Valid values applicable to specific Alarms are specified as \"Fault details\" values of the Alarm applicable to Or-Vnfm reference point, as defined in clause 7.3 of ETSI GS NFV-IFA 045 [13].\n","type":"array","items":{"type":"string"}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"objectInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualAlarm.Patch.200":{"description":"200 OK\n\nShall be returned when the request has been accepted and completed.\nThe response body shall contain attribute modifications for an \"Individual alarm\"\nresource (see clause 7.5.2.4).\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"ETag":{"description":"Used to provide the current entity-tag for the selected resource representation. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string"}},"Last-Modified":{"description":"Used to provide a timestamp indicating the date and time at which the server believes the selected resource representation was last modified. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string","format":"date-time"}}},"content":{"application/json":{"schema":{"description":"This type represents attribute modifications for an \"Individual alarm\" resource, i.e. modifications to a resource representation based on the \"Alarm\" data type. The attributes of \"Alarm\" that can be modified are included in the \"AlarmModifications\" data type.\n","type":"object","required":["ackState"],"properties":{"ackState":{"description":"New value of the \"ackState\" attribute in \"Alarm\". Permitted values: * ACKNOWLEDGED * UNACKNOWLEDGED\n","type":"string","enum":["ACKNOWLEDGED","UNACKNOWLEDGED"]}}}}}},"IndividualAlarm.Patch.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the \"Individual alarm\"\nresource.\nTypically, this is due to the fact that the alarm is\nalready in the state that is requested to be set (such\nas trying to acknowledge an already-acknowledged\nalarm).\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualAlarm.Patch.412":{"description":"412 Precondition Failed\n\nShall be returned upon the following error: A\nprecondition given in an HTTP request header is not\nfulfilled.\nTypically, this is due to an ETag mismatch, indicating\nthat the resource was modified by another entity.\nThe response body should contain a ProblemDetails\nstructure, in which the \"detail\" attribute should convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}}},"Subscriptions.Get.200":{"description":"200 OK\n\nShall be returned when the list of subscriptions has been queried successfully.\nThe response body shall contain in an array the representations of all active subscriptions\nof the functional block that invokes the method, i.e. zero or more representations of\nFM subscriptions as defined in clause 7.5.2.3.\nIf the \"filter\" URI parameter was supplied in the request, the data in the response body shall\nhave been transformed according to the rules specified in clause 5.2.2 of ETSI GS NFV-SOL 013.\nIf the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013\nfor this resource, inclusion of the Link HTTP header in this response shall follow the provisions\nin clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a subscription related to notifications about VNF faults.\n","type":"object","required":["id","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications about VNF faults.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdId"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tAlarmNotification -\tAlarmClearedNotification -\tAlarmListRebuiltNotification See note.\n","type":"array","items":{"type":"string","enum":["AlarmNotification","AlarmClearedNotification","AlarmListRebuiltNotification"]}},"faultyResourceTypes":{"description":"Match VNF alarms with a faulty resource type listed in this attribute.\n","type":"array","items":{"description":"The enumeration FaultyResourceType represents those types of faulty resource.\n","type":"string","enum":["COMPUTE","STORAGE","NETWORK"]}},"perceivedSeverities":{"description":"Match VNF alarms with a perceived severity listed in this attribute.\n","type":"array","items":{"description":"Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n","type":"string","enum":["CRITICAL","MAJOR","MINOR","WARNING","INDETERMINATE","CLEARED"]}},"eventTypes":{"description":"Match VNF alarms with an event type listed in this attribute.\n","type":"array","items":{"description":"The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment fault (ITU-T Recommendation X.733).\n","type":"string","enum":["COMMUNICATIONS_ALARM","PROCESSING_ERROR_ALARM","ENVIRONMENTAL_ALARM","QOS_ALARM","EQUIPMENT_ALARM"]}},"probableCauses":{"description":"Match VNF alarms with a probable cause listed in this attribute.\n","type":"array","items":{"type":"string"}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"fmConnection":{"description":"An access information and interface information to monitor the FM of VNF instance by the VNFM. This can include for instance certain interface endpoint URI together with necessary credentials to access it.\n","type":"array","items":{"description":"The MonitoringConnection shall follow the indications provided.\n* NOTE: The VNFM can be made aware of monitoring connection information, including their identifiers to be used by configuration means outside the scope of the \n present document (e.g. using relevant NFV-MANO management APIs as defined in \n ETSI GS NFV-SOL 009 [i.18]).\n","type":"object","required":["id","monitoringType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"monitoringType":{"description":"Type of monitoring way.\n","type":"string","enum":["VIM_CISM","EXTERNAL","PAAS"]},"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"Subscriptions.Post.200":{"description":"201 CREATED\n\nShall be returned when the subscription has been created successfully.\nThe response body shall contain a representation of the created \"Individual subscription\" resource.\nThe HTTP response shall include a \"Location:\"\" HTTP header that points to the created\n\"Individual subscription\" resource.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{"application/json":{"schema":{"description":"This type represents a subscription related to notifications about VNF faults.\n","type":"object","required":["id","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications about VNF faults.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdId"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tAlarmNotification -\tAlarmClearedNotification -\tAlarmListRebuiltNotification See note.\n","type":"array","items":{"type":"string","enum":["AlarmNotification","AlarmClearedNotification","AlarmListRebuiltNotification"]}},"faultyResourceTypes":{"description":"Match VNF alarms with a faulty resource type listed in this attribute.\n","type":"array","items":{"description":"The enumeration FaultyResourceType represents those types of faulty resource.\n","type":"string","enum":["COMPUTE","STORAGE","NETWORK"]}},"perceivedSeverities":{"description":"Match VNF alarms with a perceived severity listed in this attribute.\n","type":"array","items":{"description":"Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n","type":"string","enum":["CRITICAL","MAJOR","MINOR","WARNING","INDETERMINATE","CLEARED"]}},"eventTypes":{"description":"Match VNF alarms with an event type listed in this attribute.\n","type":"array","items":{"description":"The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment fault (ITU-T Recommendation X.733).\n","type":"string","enum":["COMMUNICATIONS_ALARM","PROCESSING_ERROR_ALARM","ENVIRONMENTAL_ALARM","QOS_ALARM","EQUIPMENT_ALARM"]}},"probableCauses":{"description":"Match VNF alarms with a probable cause listed in this attribute.\n","type":"array","items":{"type":"string"}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"fmConnection":{"description":"An access information and interface information to monitor the FM of VNF instance by the VNFM. This can include for instance certain interface endpoint URI together with necessary credentials to access it.\n","type":"array","items":{"description":"The MonitoringConnection shall follow the indications provided.\n* NOTE: The VNFM can be made aware of monitoring connection information, including their identifiers to be used by configuration means outside the scope of the \n present document (e.g. using relevant NFV-MANO management APIs as defined in \n ETSI GS NFV-SOL 009 [i.18]).\n","type":"object","required":["id","monitoringType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"monitoringType":{"description":"Type of monitoring way.\n","type":"string","enum":["VIM_CISM","EXTERNAL","PAAS"]},"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"Subscriptions.Post.303":{"description":"303 See Other\n\nShall be returned when a subscription with the\nsame callback URI and the same filter already\nexists and the policy of the VNFM is to not create\nredundant subscriptions.\nThe HTTP response shall include a \"Location\"\nHTTP header that contains the resource URI of\nthe existing \"Individual subscription\" resource.\nThe response body shall be empty.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}}},"Subscriptions.Post.422":{"description":"422 Unprocessable Content\n\nShall be returned upon the following error: The\ncontent type of the message content is supported\nand the message content of a request contains\nsyntactically correct data but the data cannot be\nprocessed.\nThe general cause for this error and its handling\nis specified in clause 6.4 of ETSI\nGS NFV-SOL 013 [8], including rules for the\npresence of the response body.\nSpecifically in case of this resource, the response\ncode 422 shall also be returned if the VNFM has\ntested the Notification endpoint as described in\nclause 7.4.6.3.2 and the test has failed.\nIn this case, the \"detail\" attribute in the\n\"ProblemDetails\" structure shall convey more\ninformation about the error\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualSubscription.Get.200":{"description":"200 OK\n\nThe operation has completed successfully.\nThe response body shall contain a representation of the\nsubscription resource.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a subscription related to notifications about VNF faults.\n","type":"object","required":["id","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications about VNF faults.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdId"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tAlarmNotification -\tAlarmClearedNotification -\tAlarmListRebuiltNotification See note.\n","type":"array","items":{"type":"string","enum":["AlarmNotification","AlarmClearedNotification","AlarmListRebuiltNotification"]}},"faultyResourceTypes":{"description":"Match VNF alarms with a faulty resource type listed in this attribute.\n","type":"array","items":{"description":"The enumeration FaultyResourceType represents those types of faulty resource.\n","type":"string","enum":["COMPUTE","STORAGE","NETWORK"]}},"perceivedSeverities":{"description":"Match VNF alarms with a perceived severity listed in this attribute.\n","type":"array","items":{"description":"Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n","type":"string","enum":["CRITICAL","MAJOR","MINOR","WARNING","INDETERMINATE","CLEARED"]}},"eventTypes":{"description":"Match VNF alarms with an event type listed in this attribute.\n","type":"array","items":{"description":"The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment fault (ITU-T Recommendation X.733).\n","type":"string","enum":["COMMUNICATIONS_ALARM","PROCESSING_ERROR_ALARM","ENVIRONMENTAL_ALARM","QOS_ALARM","EQUIPMENT_ALARM"]}},"probableCauses":{"description":"Match VNF alarms with a probable cause listed in this attribute.\n","type":"array","items":{"type":"string"}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"fmConnection":{"description":"An access information and interface information to monitor the FM of VNF instance by the VNFM. This can include for instance certain interface endpoint URI together with necessary credentials to access it.\n","type":"array","items":{"description":"The MonitoringConnection shall follow the indications provided.\n* NOTE: The VNFM can be made aware of monitoring connection information, including their identifiers to be used by configuration means outside the scope of the \n present document (e.g. using relevant NFV-MANO management APIs as defined in \n ETSI GS NFV-SOL 009 [i.18]).\n","type":"object","required":["id","monitoringType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"monitoringType":{"description":"Type of monitoring way.\n","type":"string","enum":["VIM_CISM","EXTERNAL","PAAS"]},"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualSubscription.Delete.204":{"description":"204 NO CONTENT\n\nShall be returned when the \"Individual subscription\" resource has been deleted successfully.\nThe response body shall be empty.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{}}}}} diff --git a/v5.3.1/SOL003-VNFFaultManagement-API.yaml b/v5.3.1/SOL003-VNFFaultManagement-API.yaml new file mode 100644 index 00000000..628621ca --- /dev/null +++ b/v5.3.1/SOL003-VNFFaultManagement-API.yaml @@ -0,0 +1,11430 @@ +openapi: 3.0.2 +info: + title: SOL003 - VNF Fault Management interface + description: | + SOL003 - VNF Fault Management interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '1.14.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 003 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf +servers: + - url: 'http://127.0.0.1/vnffm/v1' + - url: 'https://127.0.0.1/vnffm/v1' +paths: + /api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /alarms: + get: + description: > + The API consumer can use this method to retrieve information about the + alarm list. See clause 7.4.2.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + - $ref: '#/components/parameters/filter_alarm_list' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this + resource. + in: query + required: false + schema: + type: string + responses: + '200': + $ref: '#/components/responses/Alarms.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/alarms/{alarmId}': + parameters: + - $ref: '#/components/parameters/AlarmId' + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + get: + description: > + The API consumer can use this method to read an individual alarm. See + clause 7.4.3.3.2. + responses: + '200': + $ref: '#/components/responses/IndividualAlarm.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method modifies an "Individual alarm" resource. See clause + 7.4.3.3.4. + parameters: + - name: If-Unmodified-Since + description: > + Used to make the request method conditional on the selected + resource representation's last modification date being earlier than + or equal to the date provided in the field-value. If the condition + is not met, the request fails with a "412 Precondition Failed" + response. + required: false + in: header + schema: + type: string + format: date-time + - name: If-Match + description: > + Used to make the request method conditional on the recipient origin + server either having at least one current representation of the + target resource, when the field-value is "*", or having a current + representation of the target resource that has an entity-tag + matching a member of the list of entity-tags provided in the + field-value. If the condition is not met, the request fails with a + "412 Precondition Failed" response. + required: false + in: header + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/IndividualAlarmRequest' + responses: + '200': + $ref: '#/components/responses/IndividualAlarm.Patch.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/IndividualAlarm.Patch.409' + '412': + $ref: '#/components/responses/IndividualAlarm.Patch.412' + '422': + description: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /subscriptions: + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + post: + description: | + The POST method creates a new subscription. See clause 7.4.4.3.1. + requestBody: + $ref: '#/components/requestBodies/FmSubscriptionRequest' + responses: + '201': + $ref: '#/components/responses/Subscriptions.Post.200' + '303': + $ref: '#/components/responses/Subscriptions.Post.303' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/Subscriptions.Post.422' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + get: + description: > + The API consumer can use this method to retrieve the list of active + subscriptions for VNF alarms subscribed + + by the API consumer. It can be used e.g. for resynchronization after + error situations. See clause 7.4.4.3.2. + parameters: + - $ref: '#/components/parameters/filter_subscriptions' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this + resource. + in: query + required: false + schema: + type: string + responses: + '200': + $ref: '#/components/responses/Subscriptions.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/subscriptions/{subscriptionId}': + parameters: + - $ref: '#/components/parameters/SubscriptionId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The API consumer can use this method for reading an individual + subscription for VNF + + alarms subscribed by the API consumer. See clause 7.4.5.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualSubscription.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: | + This method terminates an individual subscription. See clause 7.4.5.3.5. + responses: + '204': + $ref: '#/components/responses/IndividualSubscription.Delete.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + parameters: + filter_alarm_list: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part + of the URI query string. The NFVO may supply this parameter. The + following attribute names shall be supported by the VNFM in the + attribute based filtering expression: id, managedObjectId, + rootCauseFaultyResource/faultyResourceType, eventType, + perceivedSeverity, probableCause. + in: query + required: false + schema: + type: string + filter_subscriptions: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part + of the URI query string. The NFVO may supply this parameter. All + attribute names that appear in the FmSubscription and in data types + referenced from it shall be supported by the VNFM in the filter + expression. + in: query + required: false + schema: + type: string + AlarmId: + name: alarmId + in: path + description: > + Identifier of the alarm. + + This identifier can be retrieved from the "id" attribute of the "alarm" + attribute in the AlarmNotification or + + AlarmClearedNotification. It can also be retrieved from the "id" + attribute of the applicable array element in + + the message content of the response to a GET request to the "Alarms" + resource. + required: true + style: simple + explode: false + schema: + type: string + SubscriptionId: + name: subscriptionId + in: path + description: > + Identifier of this subscription. + + This identifier can be retrieved from the resource referenced by the + + "Location" HTTP header in the response to a POST request creating a + + new "Individual subscription" resource. It can also be retrieved from + the "id" + + attribute in the message content of that response. + required: true + style: simple + explode: false + schema: + type: string + requestBodies: + IndividualAlarmRequest: + description: The VNF creation parameters + content: + application/merge-patch+json: + schema: + description: > + This type represents attribute modifications for an "Individual + alarm" resource, i.e. modifications to a resource representation + based on the "Alarm" data type. The attributes of "Alarm" that can + be modified are included in the "AlarmModifications" data type. + type: object + required: + - ackState + properties: + ackState: + description: > + New value of the "ackState" attribute in "Alarm". Permitted + values: * ACKNOWLEDGED * UNACKNOWLEDGED + type: string + enum: + - ACKNOWLEDGED + - UNACKNOWLEDGED + required: true + FmSubscriptionRequest: + description: The VNF creation parameters + content: + application/json: + schema: + description: > + This type represents a subscription request related to + notifications about VNF faults. + type: object + required: + - callbackUri + properties: + filter: + description: "This type represents a subscription filter related to notifications about VNF faults.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdId + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId values + listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, from + one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tAlarmNotification -\tAlarmClearedNotification -\tAlarmListRebuiltNotification See note.\n" + type: array + items: + type: string + enum: + - AlarmNotification + - AlarmClearedNotification + - AlarmListRebuiltNotification + faultyResourceTypes: + description: > + Match VNF alarms with a faulty resource type listed in + this attribute. + type: array + items: + description: > + The enumeration FaultyResourceType represents those + types of faulty resource. + type: string + enum: + - COMPUTE + - STORAGE + - NETWORK + perceivedSeverities: + description: > + Match VNF alarms with a perceived severity listed in this + attribute. + type: array + items: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level + indicates that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a + service affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the + existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the + detection of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level + indicates that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the + clearing of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTypes: + description: > + Match VNF alarms with an event type listed in this + attribute. + type: array + items: + description: > + The enumeration EventType represents those types of + events that trigger an alarm. * COMMUNICATIONS_ALARM: An + alarm of this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is + associated with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is + associated with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated + with an equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + probableCauses: + description: > + Match VNF alarms with a probable cause listed in this + attribute. + type: array + items: + type: string + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + authentication: + description: > + * NOTE 1 : The clientId and clientPassword passed in a + subscription shall not be the same as the clientId and + clientPassword that are used to obtain authorization for API requests. Client credentials may differ between + subscriptions. The value of clientPassword should be generated by a random process. + * NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT + which uses mutual authentication based on X.509 + certificates, this mode which uses client password to authenticate may be used in the access token request + toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations + (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details. + * NOTE 3: The following values that were included up to + version 3.4.1 of the present document have been removed: + "BASIC" (to signal the use of the basic HTTP authentication) has been removed because it is insecure. + "TLS_CERT" to signal an alternative non-token based authorization method using TLS certificates has been + removed because the method is no longer supported. + * NOTE 4: The client certificate is established by means + outside the scope of the present document. + type: object + required: + - authType + properties: + authType: + description: > + Defines the types of Authentication / Authorization which + the API consumer is willing to accept when receiving a + notification. Permitted values (see note 3): * + OAUTH2_CLIENT_CREDENTIALS: In every + HTTP request to the notification endpoint, use + an OAuth 2.0 token, obtained using the client + credentials grant type after authenticating + using client identifier and client password + towards the token endpoint. + * OAUTH2_CLIENT_CERT: In every HTTP + request to the notification endpoint, use an + OAuth 2.0 token, obtained using the client + credentials grant type after mutually + authenticating using client identifier and X.509 + certificates towards the token endpoint. + type: array + items: + type: string + enum: + - OAUTH2_CLIENT_CREDENTIALS + - OAUTH2_CLIENT_CERT + paramsOauth2ClientCert: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CERT. + + Shall be present if authType is "OAUTH2_CLIENT_CERT" and + the contained information has not been provisioned out of + band. + + Shall be absent otherwise. + type: object + required: + - clientId + - certificateRef + - tokenEndpoint + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. + type: string + certificateRef: + description: > + Fingerprint of the client certificate. The hash + function shall use SHA256 or higher. See note 4. + type: string + required: + - type + - value + properties: + type: + description: | + A string defined in IETF RFC 8259. + type: string + value: + description: | + A string defined in IETF RFC 8259. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + paramsOauth2ClientCredentials: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CREDENTIALS. + + Shall be present if authType is + "OAUTH2_CLIENT_CREDENTIALS" and the contained information + has not been provisioned out of band. + + Shall be absent otherwise. + + See note 2. + type: object + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. Shall be present if it has not been + provisioned out of band. See note 1. + type: string + clientPassword: + description: > + Client password to be used in the access token request + of the OAuth 2.0 client credentials grant type. Shall + be present if it has not been provisioned out of band. + See note 1. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + responses: + Alarms.Get.200: + description: > + 200 OK + + + Shall be returned when information about zero or more alarms has been + queried successfully. + + The response body shall contain in an array the representations of zero + or more alarms as + + defined in clause 7.5.2.4. + + If the "filter" URI parameter was supplied in the request, the data in + the response body + + shall have been transformed according to the rules specified in clause + 5.2.2 of ETSI GS NFV-SOL 013. + + If the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 + of ETSI GS NFV-SOL 013 + + for this resource, inclusion of the Link HTTP header in this response + shall follow the provisions + + in clause 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The alarm data type encapsulates information about an alarm. + + NOTE 1: For an alarm about upcoming impact due to NFVI operation + and maintenance (i.e. the attribute + "faultType" has the value "NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE"), the attribute + "rootCauseFaultyResource" indicates a resource to be impacted. Further information on the upcoming + impact (e.g. group of impacted resources, time of impact) is provided in the attribute "faultDetails". + NOTE 2: When alarms are due to upcoming NFVI operation and + maintenance (i.e. the attribute "faultType" has the + value "NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE"), the attribute "faultDetails" shall include + information about the anticipated time of the maintenance. See provisions under the present table. + + If the attribute "faultType" has the value + "NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE", the following + provisions apply for the values of the attribute "faultDetails" + related to changes in the state of virtualised resources: + - One of the entries in the array shall provide information about the anticipated time of maintenance in the + following format: "anticipatedTime=$time", wherein "$time" shall be formatted as a "DateTime", as specified + in ETSI GS NFV-SOL 013 [8]. + - One of the entries in the array shall provide identification information about the affinity/anti-affinity + group defined in the VNFD that is associated to the affected virtualised resource indicated by + "rootCauseFaultyResource" in the following format: "affinityOrAntiAffinityGroupId=$group", wherein + "$group" shall be equal to the "affinityOrAntiAffinityGroupId" value in the corresponding "VduProfile" (for a + VNFC/COMPUTE affected resource) or "VirtualLinkProfile" for a VL/NETWORK affected resource) in the + VNFD, which is mapped by the VNFM to the virtualised resource group identifier in the virtualised resource + change notification received by the VNFM from the VIM. + type: object + required: + - id + - managedObjectId + - alarmRaisedTime + - ackState + - perceivedSeverity + - eventTime + - eventType + - probableCause + - isRootCause + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + managedObjectId: + description: | + An identifier with the intention of being globally unique. + type: string + rootCauseFaultyResource: + description: > + This type represents the faulty virtual resources that have a + negative impact on a VNF. + type: object + required: + - faultyResource + - faultyResourceType + properties: + faultyResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available from + the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId shall + be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is allocated. + It shall be present for compute resources in the + scope of the CISM and shall be absent otherwise. + See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is managed + by a CISM and it shall be absent otherwise. + type: string + faultyResourceType: + description: > + The enumeration FaultyResourceType represents those types + of faulty resource. + type: string + enum: + - COMPUTE + - STORAGE + - NETWORK + alarmRaisedTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + alarmChangedTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + alarmClearedTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + alarmAcknowledgedTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + ackState: + description: > + Acknowledgement state of the alarm. Permitted values: * + UNACKNOWLEDGED * ACKNOWLEDGED. + type: string + enum: + - UNACKNOWLEDGED + - ACKNOWLEDGED + perceivedSeverity: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level indicates + that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a service + affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the detection + of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level indicates + that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the clearing + of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + eventType: + description: > + The enumeration EventType represents those types of events + that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of + this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is associated + with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is associated + with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated with an + equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + faultType: + description: > + Additional information to clarify the type of the fault. Valid + values applicable to specific Alarms are specified as "Alarm + definition identifier" values of the Alarm applicable to + Or-Vnfm reference point, as defined in clause 7.3 of ETSI GS + NFV-IFA 045 [13]. If the alarm is related to changes in the + state of virtualised resources due to NFVI operation and + maintenance, this attribute shall be set to + "NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE". + type: string + probableCause: + description: > + Information about the probable cause of the fault. Valid + values applicable to specific Alarms are specified as + "Probable cause" values of the Alarm applicable to Or-Vnfm + reference point, as defined in clause 7.3 of ETSI GS NFV-IFA + 045 [13]. If the attribute "faultType" has the value + “NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE”, the permitted + values are: + - "NFVI_COMPONENT_MAINTENANCE": Maintenance of NFVI components, e.g. + physical maintenance/repair, hypervisor software updates, etc. + - "NFVI_COMPONENT_EVACUATION": Evacuation of physical hosts. + - "NFVI_COMPONENT_OPTIMIZATION": Operation and management of NFVI resources, e.g. + to support energy efficiency or resource usage. + type: string + isRootCause: + description: > + Attribute indicating if this fault is the root for other + correlated alarms. If true, then the alarms listed in the + attribute "correlatedAlarmIds" are caused by this fault. + type: boolean + correlatedAlarmIds: + description: | + List of identifiers of other alarms correlated to this fault. + type: array + items: + description: | + An identifier with the intention of being globally unique. + type: string + faultDetails: + description: > + Provides additional information about the fault. See notes 1 + and 2. Valid values applicable to specific Alarms are + specified as "Fault details" values of the Alarm applicable + to Or-Vnfm reference point, as defined in clause 7.3 of ETSI + GS NFV-IFA 045 [13]. + type: array + items: + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + objectInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualAlarm.Get.200: + description: > + 200 OK + + + Shall be returned when information about an individual alarm has been + read successfully. + + The response body shall contain a representation of the individual alarm + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + ETag: + description: > + Used to provide the current entity-tag for the selected resource + representation. It can be sent in "200 OK", "201 Created" and "204 + No Content" responses. + style: simple + schema: + type: string + Last-Modified: + description: > + Used to provide a timestamp indicating the date and time at which + the server believes the selected resource representation was last + modified. It can be sent in "200 OK", "201 Created" and "204 No + Content" responses. + style: simple + schema: + type: string + format: date-time + content: + application/json: + schema: + description: > + The alarm data type encapsulates information about an alarm. + + NOTE 1: For an alarm about upcoming impact due to NFVI operation + and maintenance (i.e. the attribute + "faultType" has the value "NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE"), the attribute + "rootCauseFaultyResource" indicates a resource to be impacted. Further information on the upcoming + impact (e.g. group of impacted resources, time of impact) is provided in the attribute "faultDetails". + NOTE 2: When alarms are due to upcoming NFVI operation and + maintenance (i.e. the attribute "faultType" has the + value "NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE"), the attribute "faultDetails" shall include + information about the anticipated time of the maintenance. See provisions under the present table. + + If the attribute "faultType" has the value + "NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE", the following + provisions apply for the values of the attribute "faultDetails" + related to changes in the state of virtualised resources: + - One of the entries in the array shall provide information about the anticipated time of maintenance in the + following format: "anticipatedTime=$time", wherein "$time" shall be formatted as a "DateTime", as specified + in ETSI GS NFV-SOL 013 [8]. + - One of the entries in the array shall provide identification information about the affinity/anti-affinity + group defined in the VNFD that is associated to the affected virtualised resource indicated by + "rootCauseFaultyResource" in the following format: "affinityOrAntiAffinityGroupId=$group", wherein + "$group" shall be equal to the "affinityOrAntiAffinityGroupId" value in the corresponding "VduProfile" (for a + VNFC/COMPUTE affected resource) or "VirtualLinkProfile" for a VL/NETWORK affected resource) in the + VNFD, which is mapped by the VNFM to the virtualised resource group identifier in the virtualised resource + change notification received by the VNFM from the VIM. + type: object + required: + - id + - managedObjectId + - alarmRaisedTime + - ackState + - perceivedSeverity + - eventTime + - eventType + - probableCause + - isRootCause + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + managedObjectId: + description: | + An identifier with the intention of being globally unique. + type: string + rootCauseFaultyResource: + description: > + This type represents the faulty virtual resources that have a + negative impact on a VNF. + type: object + required: + - faultyResource + - faultyResourceType + properties: + faultyResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available from + the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId shall + be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is allocated. + It shall be present for compute resources in the + scope of the CISM and shall be absent otherwise. + See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is managed + by a CISM and it shall be absent otherwise. + type: string + faultyResourceType: + description: > + The enumeration FaultyResourceType represents those types + of faulty resource. + type: string + enum: + - COMPUTE + - STORAGE + - NETWORK + alarmRaisedTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + alarmChangedTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + alarmClearedTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + alarmAcknowledgedTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + ackState: + description: > + Acknowledgement state of the alarm. Permitted values: * + UNACKNOWLEDGED * ACKNOWLEDGED. + type: string + enum: + - UNACKNOWLEDGED + - ACKNOWLEDGED + perceivedSeverity: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level indicates + that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a service + affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the detection + of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level indicates + that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the clearing + of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + eventType: + description: > + The enumeration EventType represents those types of events + that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of + this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is associated + with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is associated + with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated with an + equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + faultType: + description: > + Additional information to clarify the type of the fault. Valid + values applicable to specific Alarms are specified as "Alarm + definition identifier" values of the Alarm applicable to + Or-Vnfm reference point, as defined in clause 7.3 of ETSI GS + NFV-IFA 045 [13]. If the alarm is related to changes in the + state of virtualised resources due to NFVI operation and + maintenance, this attribute shall be set to + "NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE". + type: string + probableCause: + description: > + Information about the probable cause of the fault. Valid + values applicable to specific Alarms are specified as + "Probable cause" values of the Alarm applicable to Or-Vnfm + reference point, as defined in clause 7.3 of ETSI GS NFV-IFA + 045 [13]. If the attribute "faultType" has the value + “NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE”, the permitted + values are: + - "NFVI_COMPONENT_MAINTENANCE": Maintenance of NFVI components, e.g. + physical maintenance/repair, hypervisor software updates, etc. + - "NFVI_COMPONENT_EVACUATION": Evacuation of physical hosts. + - "NFVI_COMPONENT_OPTIMIZATION": Operation and management of NFVI resources, e.g. + to support energy efficiency or resource usage. + type: string + isRootCause: + description: > + Attribute indicating if this fault is the root for other + correlated alarms. If true, then the alarms listed in the + attribute "correlatedAlarmIds" are caused by this fault. + type: boolean + correlatedAlarmIds: + description: | + List of identifiers of other alarms correlated to this fault. + type: array + items: + description: | + An identifier with the intention of being globally unique. + type: string + faultDetails: + description: > + Provides additional information about the fault. See notes 1 + and 2. Valid values applicable to specific Alarms are + specified as "Fault details" values of the Alarm applicable + to Or-Vnfm reference point, as defined in clause 7.3 of ETSI + GS NFV-IFA 045 [13]. + type: array + items: + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + objectInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualAlarm.Patch.200: + description: > + 200 OK + + + Shall be returned when the request has been accepted and completed. + + The response body shall contain attribute modifications for an + "Individual alarm" + + resource (see clause 7.5.2.4). + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + ETag: + description: > + Used to provide the current entity-tag for the selected resource + representation. It can be sent in "200 OK", "201 Created" and "204 + No Content" responses. + style: simple + schema: + type: string + Last-Modified: + description: > + Used to provide a timestamp indicating the date and time at which + the server believes the selected resource representation was last + modified. It can be sent in "200 OK", "201 Created" and "204 No + Content" responses. + style: simple + schema: + type: string + format: date-time + content: + application/json: + schema: + description: > + This type represents attribute modifications for an "Individual + alarm" resource, i.e. modifications to a resource representation + based on the "Alarm" data type. The attributes of "Alarm" that can + be modified are included in the "AlarmModifications" data type. + type: object + required: + - ackState + properties: + ackState: + description: > + New value of the "ackState" attribute in "Alarm". Permitted + values: * ACKNOWLEDGED * UNACKNOWLEDGED + type: string + enum: + - ACKNOWLEDGED + - UNACKNOWLEDGED + IndividualAlarm.Patch.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the "Individual alarm" + resource. + Typically, this is due to the fact that the alarm is + already in the state that is requested to be set (such + as trying to acknowledge an already-acknowledged + alarm). + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualAlarm.Patch.412: + description: | + 412 Precondition Failed + + Shall be returned upon the following error: A + precondition given in an HTTP request header is not + fulfilled. + Typically, this is due to an ETag mismatch, indicating + that the resource was modified by another entity. + The response body should contain a ProblemDetails + structure, in which the "detail" attribute should convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + Subscriptions.Get.200: + description: > + 200 OK + + + Shall be returned when the list of subscriptions has been queried + successfully. + + The response body shall contain in an array the representations of all + active subscriptions + + of the functional block that invokes the method, i.e. zero or more + representations of + + FM subscriptions as defined in clause 7.5.2.3. + + If the "filter" URI parameter was supplied in the request, the data in + the response body shall + + have been transformed according to the rules specified in clause 5.2.2 + of ETSI GS NFV-SOL 013. + + If the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 + of ETSI GS NFV-SOL 013 + + for this resource, inclusion of the Link HTTP header in this response + shall follow the provisions + + in clause 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + This type represents a subscription related to notifications about + VNF faults. + type: object + required: + - id + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: "This type represents a subscription filter related to notifications about VNF faults.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdId + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId values + listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, from + one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tAlarmNotification -\tAlarmClearedNotification -\tAlarmListRebuiltNotification See note.\n" + type: array + items: + type: string + enum: + - AlarmNotification + - AlarmClearedNotification + - AlarmListRebuiltNotification + faultyResourceTypes: + description: > + Match VNF alarms with a faulty resource type listed in + this attribute. + type: array + items: + description: > + The enumeration FaultyResourceType represents those + types of faulty resource. + type: string + enum: + - COMPUTE + - STORAGE + - NETWORK + perceivedSeverities: + description: > + Match VNF alarms with a perceived severity listed in this + attribute. + type: array + items: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level + indicates that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a + service affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the + existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the + detection of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level + indicates that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the + clearing of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTypes: + description: > + Match VNF alarms with an event type listed in this + attribute. + type: array + items: + description: > + The enumeration EventType represents those types of + events that trigger an alarm. * COMMUNICATIONS_ALARM: An + alarm of this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is + associated with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is + associated with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated + with an equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + probableCauses: + description: > + Match VNF alarms with a probable cause listed in this + attribute. + type: array + items: + type: string + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + fmConnection: + description: > + An access information and interface information to monitor the + FM of VNF instance by the VNFM. This can include for instance + certain interface endpoint URI together with necessary + credentials to access it. + type: array + items: + description: > + The MonitoringConnection shall follow the indications + provided. + + * NOTE: The VNFM can be made aware of monitoring connection + information, + including their identifiers to be used by configuration means outside the scope of the + present document (e.g. using relevant NFV-MANO management APIs as defined in + ETSI GS NFV-SOL 009 [i.18]). + type: object + required: + - id + - monitoringType + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + monitoringType: + description: | + Type of monitoring way. + type: string + enum: + - VIM_CISM + - EXTERNAL + - PAAS + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being globally + unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: | + A string defined in IETF RFC 8259. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + Subscriptions.Post.200: + description: > + 201 CREATED + + + Shall be returned when the subscription has been created successfully. + + The response body shall contain a representation of the created + "Individual subscription" resource. + + The HTTP response shall include a "Location:"" HTTP header that points + to the created + + "Individual subscription" resource. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + content: + application/json: + schema: + description: > + This type represents a subscription related to notifications about + VNF faults. + type: object + required: + - id + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: "This type represents a subscription filter related to notifications about VNF faults.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdId + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId values + listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, from + one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tAlarmNotification -\tAlarmClearedNotification -\tAlarmListRebuiltNotification See note.\n" + type: array + items: + type: string + enum: + - AlarmNotification + - AlarmClearedNotification + - AlarmListRebuiltNotification + faultyResourceTypes: + description: > + Match VNF alarms with a faulty resource type listed in + this attribute. + type: array + items: + description: > + The enumeration FaultyResourceType represents those + types of faulty resource. + type: string + enum: + - COMPUTE + - STORAGE + - NETWORK + perceivedSeverities: + description: > + Match VNF alarms with a perceived severity listed in this + attribute. + type: array + items: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level + indicates that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a + service affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the + existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the + detection of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level + indicates that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the + clearing of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTypes: + description: > + Match VNF alarms with an event type listed in this + attribute. + type: array + items: + description: > + The enumeration EventType represents those types of + events that trigger an alarm. * COMMUNICATIONS_ALARM: An + alarm of this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is + associated with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is + associated with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated + with an equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + probableCauses: + description: > + Match VNF alarms with a probable cause listed in this + attribute. + type: array + items: + type: string + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + fmConnection: + description: > + An access information and interface information to monitor the + FM of VNF instance by the VNFM. This can include for instance + certain interface endpoint URI together with necessary + credentials to access it. + type: array + items: + description: > + The MonitoringConnection shall follow the indications + provided. + + * NOTE: The VNFM can be made aware of monitoring connection + information, + including their identifiers to be used by configuration means outside the scope of the + present document (e.g. using relevant NFV-MANO management APIs as defined in + ETSI GS NFV-SOL 009 [i.18]). + type: object + required: + - id + - monitoringType + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + monitoringType: + description: | + Type of monitoring way. + type: string + enum: + - VIM_CISM + - EXTERNAL + - PAAS + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being globally + unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: | + A string defined in IETF RFC 8259. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + Subscriptions.Post.303: + description: | + 303 See Other + + Shall be returned when a subscription with the + same callback URI and the same filter already + exists and the policy of the VNFM is to not create + redundant subscriptions. + The HTTP response shall include a "Location" + HTTP header that contains the resource URI of + the existing "Individual subscription" resource. + The response body shall be empty. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + Subscriptions.Post.422: + description: | + 422 Unprocessable Content + + Shall be returned upon the following error: The + content type of the message content is supported + and the message content of a request contains + syntactically correct data but the data cannot be + processed. + The general cause for this error and its handling + is specified in clause 6.4 of ETSI + GS NFV-SOL 013 [8], including rules for the + presence of the response body. + Specifically in case of this resource, the response + code 422 shall also be returned if the VNFM has + tested the Notification endpoint as described in + clause 7.4.6.3.2 and the test has failed. + In this case, the "detail" attribute in the + "ProblemDetails" structure shall convey more + information about the error + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualSubscription.Get.200: + description: | + 200 OK + + The operation has completed successfully. + The response body shall contain a representation of the + subscription resource. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + This type represents a subscription related to notifications about + VNF faults. + type: object + required: + - id + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: "This type represents a subscription filter related to notifications about VNF faults.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdId + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId values + listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, from + one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tAlarmNotification -\tAlarmClearedNotification -\tAlarmListRebuiltNotification See note.\n" + type: array + items: + type: string + enum: + - AlarmNotification + - AlarmClearedNotification + - AlarmListRebuiltNotification + faultyResourceTypes: + description: > + Match VNF alarms with a faulty resource type listed in + this attribute. + type: array + items: + description: > + The enumeration FaultyResourceType represents those + types of faulty resource. + type: string + enum: + - COMPUTE + - STORAGE + - NETWORK + perceivedSeverities: + description: > + Match VNF alarms with a perceived severity listed in this + attribute. + type: array + items: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level + indicates that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a + service affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the + existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the + detection of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level + indicates that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the + clearing of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTypes: + description: > + Match VNF alarms with an event type listed in this + attribute. + type: array + items: + description: > + The enumeration EventType represents those types of + events that trigger an alarm. * COMMUNICATIONS_ALARM: An + alarm of this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is + associated with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is + associated with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated + with an equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + probableCauses: + description: > + Match VNF alarms with a probable cause listed in this + attribute. + type: array + items: + type: string + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + fmConnection: + description: > + An access information and interface information to monitor the + FM of VNF instance by the VNFM. This can include for instance + certain interface endpoint URI together with necessary + credentials to access it. + type: array + items: + description: > + The MonitoringConnection shall follow the indications + provided. + + * NOTE: The VNFM can be made aware of monitoring connection + information, + including their identifiers to be used by configuration means outside the scope of the + present document (e.g. using relevant NFV-MANO management APIs as defined in + ETSI GS NFV-SOL 009 [i.18]). + type: object + required: + - id + - monitoringType + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + monitoringType: + description: | + Type of monitoring way. + type: string + enum: + - VIM_CISM + - EXTERNAL + - PAAS + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being globally + unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: | + A string defined in IETF RFC 8259. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualSubscription.Delete.204: + description: > + 204 NO CONTENT + + + Shall be returned when the "Individual subscription" resource has been + deleted successfully. + + The response body shall be empty. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + content: {} + diff --git a/v5.3.1/SOL003-VNFFaultManagementNotification-API.json b/v5.3.1/SOL003-VNFFaultManagementNotification-API.json new file mode 100644 index 00000000..2b859ea8 --- /dev/null +++ b/v5.3.1/SOL003-VNFFaultManagementNotification-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL003 - VNF Fault Management Notification interface","description":"SOL003 - VNF Fault Management Notification interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"1.14.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 003 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/callback/v1"},{"url":"https://127.0.0.1/callback/v1"}],"paths":{"/URI_is_provided_by_the_client_when_creating_the_subscription-AlarmNotification":{"parameters":[{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"post":{"description":"The POST method notifies a VNF alarm or that the alarm list has been rebuilt. The API consumer shall have\npreviously created an \"Individual subscription\" resource with a matching filter. See clause 7.4.6.3.1.\n","parameters":[{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/AlarmNotification"},"responses":{"204":{"$ref":"#/components/responses/AlarmNotification.Post.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"get":{"description":"The GET method allows the API producer to test the notification endpoint that is provided by the\nAPI consumer, e.g. during subscription. See clause 7.4.6.3.2.\n","responses":{"204":{"$ref":"#/components/responses/AlarmNotification.Get.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/URI_is_provided_by_the_client_when_creating_the_subscription-AlarmClearedNotification":{"parameters":[{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"post":{"description":"The POST method notifies a VNF alarm or that the alarm list has been rebuilt. The API consumer shall have\npreviously created an \"Individual subscription\" resource with a matching filter. See clause 7.4.6.3.1.\n","parameters":[{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/AlarmClearedNotification"},"responses":{"204":{"$ref":"#/components/responses/AlarmClearedNotification.Post.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"get":{"description":"The GET method allows the API producer to test the notification endpoint that is provided by the\nAPI consumer, e.g. during subscription. See clause 7.4.6.3.2.\n","responses":{"204":{"$ref":"#/components/responses/AlarmClearedNotification.Get.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/URI_is_provided_by_the_client_when_creating_the_subscription-AlarmListRebuiltNotification":{"parameters":[{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"post":{"description":"The POST method notifies a VNF alarm or that the alarm list has been rebuilt. The API consumer shall have\npreviously created an \"Individual subscription\" resource with a matching filter. See clause 7.4.6.3.1.\n","parameters":[{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/AlarmListRebuiltNotification"},"responses":{"204":{"$ref":"#/components/responses/AlarmListRebuiltNotification.Post.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"get":{"description":"The GET method allows the API producer to test the notification endpoint that is provided by the\nAPI consumer, e.g. during subscription. See clause 7.4.6.3.2.\n","responses":{"204":{"$ref":"#/components/responses/AlarmListRebuiltNotification.Get.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"requestBodies":{"AlarmNotification":{"description":"Information of a VNF alarm.","content":{"application/json":{"schema":{"description":"This type represents an alarm notification about VNF faults. This notification shall be triggered by the VNFM when: * An alarm has been created. * An alarm has been updated, e.g. if the severity of the alarm has changed.\n","type":"object","required":["id","notificationType","subscriptionId","timeStamp","alarm","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"AlarmNotification\" for this notification type.\n","type":"string","enum":["AlarmNotification"]},"subscriptionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"alarm":{"description":"The alarm data type encapsulates information about an alarm.\nNOTE 1: For an alarm about upcoming impact due to NFVI operation and maintenance (i.e. the attribute \"faultType\" has the value \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE\"), the attribute \n \"rootCauseFaultyResource\" indicates a resource to be impacted. Further information on the upcoming\n impact (e.g. group of impacted resources, time of impact) is provided in the attribute \"faultDetails\".\nNOTE 2: When alarms are due to upcoming NFVI operation and maintenance (i.e. the attribute \"faultType\" has the value \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE\"), the attribute \"faultDetails\" shall include \n information about the anticipated time of the maintenance. See provisions under the present table.\n\nIf the attribute \"faultType\" has the value \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE\", the following provisions apply for the values of the attribute \"faultDetails\" related to changes in the state of virtualised resources: - One of the entries in the array shall provide information about the anticipated time of maintenance in the \n following format: \"anticipatedTime=$time\", wherein \"$time\" shall be formatted as a \"DateTime\", as specified \n in ETSI GS NFV-SOL 013 [8]. \n - One of the entries in the array shall provide identification information about the affinity/anti-affinity\n group defined in the VNFD that is associated to the affected virtualised resource indicated by \n \"rootCauseFaultyResource\" in the following format: \"affinityOrAntiAffinityGroupId=$group\", wherein \n \"$group\" shall be equal to the \"affinityOrAntiAffinityGroupId\" value in the corresponding \"VduProfile\" (for a \n VNFC/COMPUTE affected resource) or \"VirtualLinkProfile\" for a VL/NETWORK affected resource) in the \n VNFD, which is mapped by the VNFM to the virtualised resource group identifier in the virtualised resource \n change notification received by the VNFM from the VIM.\n","type":"object","required":["id","managedObjectId","alarmRaisedTime","ackState","perceivedSeverity","eventTime","eventType","probableCause","isRootCause","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"managedObjectId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"rootCauseFaultyResource":{"description":"This type represents the faulty virtual resources that have a negative impact on a VNF.\n","type":"object","required":["faultyResource","faultyResourceType"],"properties":{"faultyResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"faultyResourceType":{"description":"The enumeration FaultyResourceType represents those types of faulty resource.\n","type":"string","enum":["COMPUTE","STORAGE","NETWORK"]}}},"alarmRaisedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"alarmChangedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"alarmClearedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"alarmAcknowledgedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"ackState":{"description":"Acknowledgement state of the alarm. Permitted values: * UNACKNOWLEDGED * ACKNOWLEDGED.\n","type":"string","enum":["UNACKNOWLEDGED","ACKNOWLEDGED"]},"perceivedSeverity":{"description":"Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n","type":"string","enum":["CRITICAL","MAJOR","MINOR","WARNING","INDETERMINATE","CLEARED"]},"eventTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"eventType":{"description":"The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment fault (ITU-T Recommendation X.733).\n","type":"string","enum":["COMMUNICATIONS_ALARM","PROCESSING_ERROR_ALARM","ENVIRONMENTAL_ALARM","QOS_ALARM","EQUIPMENT_ALARM"]},"faultType":{"description":"Additional information to clarify the type of the fault. Valid values applicable to specific Alarms are specified as \"Alarm definition identifier\" values of the Alarm applicable to Or-Vnfm reference point, as defined in clause 7.3 of ETSI GS NFV-IFA 045 [13]. If the alarm is related to changes in the state of virtualised resources due to NFVI operation and maintenance, this attribute shall be set to \"NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE\".\n","type":"string"},"probableCause":{"description":"Information about the probable cause of the fault. Valid values applicable to specific Alarms are specified as \"Probable cause\" values of the Alarm applicable to Or-Vnfm reference point, as defined in clause 7.3 of ETSI GS NFV-IFA 045 [13]. If the attribute \"faultType\" has the value “NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE”, the permitted values are: - \"NFVI_COMPONENT_MAINTENANCE\": Maintenance of NFVI components, e.g. \n physical maintenance/repair, hypervisor software updates, etc.\n - \"NFVI_COMPONENT_EVACUATION\": Evacuation of physical hosts.\n - \"NFVI_COMPONENT_OPTIMIZATION\": Operation and management of NFVI resources, e.g.\n to support energy efficiency or resource usage.\n","type":"string"},"isRootCause":{"description":"Attribute indicating if this fault is the root for other correlated alarms. If true, then the alarms listed in the attribute \"correlatedAlarmIds\" are caused by this fault.\n","type":"boolean"},"correlatedAlarmIds":{"description":"List of identifiers of other alarms correlated to this fault.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"faultDetails":{"description":"Provides additional information about the fault. See notes 1 and 2. Valid values applicable to specific Alarms are specified as \"Fault details\" values of the Alarm applicable to Or-Vnfm reference point, as defined in clause 7.3 of ETSI GS NFV-IFA 045 [13].\n","type":"array","items":{"type":"string"}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"objectInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}},"_links":{"description":"Links to resources related to this notification.\n","type":"object","required":["subscription"],"properties":{"subscription":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true},"AlarmClearedNotification":{"description":"Information of the clearance of a VNF alarm","content":{"application/json":{"schema":{"description":"This type represents an alarm cleared notification about VNF faults. The notification shall be triggered by the VNFM when an alarm has been cleared.\n","type":"object","required":["id","notificationType","subscriptionId","timeStamp","alarmId","alarmClearedTime","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"AlarmClearedNotification\" for this notification type.\n","type":"string","enum":["AlarmClearedNotification"]},"subscriptionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"alarmId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"alarmClearedTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"_links":{"description":"Links to resources related to this notification.\n","type":"object","required":["subscription","alarm"],"properties":{"subscription":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"alarm":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true},"AlarmListRebuiltNotification":{"description":"Information that the alarm list has been rebuilt by the VNFM","content":{"application/json":{"schema":{"description":"This type represents a notification that the alarm list has been rebuilt, e.g. if the VNFM detects its storage holding the alarm list is corrupted. The notification shall be triggered by the VNFM when the alarm list has been rebuilt, e.g. because the VNFM has detected that its storage holding the alarm list was corrupted.\n","type":"object","required":["id","notificationType","subscriptionId","timeStamp","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"AlarmListRebuiltNotification\" for this notification type.\n","type":"string","enum":["AlarmListRebuiltNotification"]},"subscriptionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"_links":{"description":"Links to resources related to this notification.\n","type":"object","required":["subscription","alarms"],"properties":{"subscription":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"alarms":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true}},"responses":{"AlarmNotification.Post.204":{"description":"204 NO CONTENT\n\nShall be returned when the notification has been delivered successfully.\nThe response body shall be empty.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","style":"simple","explode":false,"schema":{"type":"string"}}}},"AlarmNotification.Get.204":{"description":"204 NO CONTENT\n\nShall be returned to indicate that the notification endpoint has been tested successfully.\nThe response body shall be empty.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","style":"simple","explode":false,"schema":{"type":"string"}}}},"AlarmClearedNotification.Post.204":{"description":"204 NO CONTENT\n\nShall be returned when the notification has been delivered successfully.\nThe response body shall be empty.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","style":"simple","explode":false,"schema":{"type":"string"}}}},"AlarmClearedNotification.Get.204":{"description":"204 NO CONTENT\n\nShall be returned to indicate that the notification endpoint has been tested successfully.\nThe response body shall be empty.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","style":"simple","explode":false,"schema":{"type":"string"}}}},"AlarmListRebuiltNotification.Post.204":{"description":"204 NO CONTENT\n\nShall be returned when the notification has been delivered successfully.\nThe response body shall be empty.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","style":"simple","explode":false,"schema":{"type":"string"}}}},"AlarmListRebuiltNotification.Get.204":{"description":"204 NO CONTENT\n\nShall be returned to indicate that the notification endpoint has been tested successfully.\nThe response body shall be empty.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","style":"simple","explode":false,"schema":{"type":"string"}}}}}}} diff --git a/v5.3.1/SOL003-VNFFaultManagementNotification-API.yaml b/v5.3.1/SOL003-VNFFaultManagementNotification-API.yaml new file mode 100644 index 00000000..79b36541 --- /dev/null +++ b/v5.3.1/SOL003-VNFFaultManagementNotification-API.yaml @@ -0,0 +1,4989 @@ +openapi: 3.0.2 +info: + title: SOL003 - VNF Fault Management Notification interface + description: | + SOL003 - VNF Fault Management Notification interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '1.14.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 003 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf +servers: + - url: 'http://127.0.0.1/callback/v1' + - url: 'https://127.0.0.1/callback/v1' +paths: + /URI_is_provided_by_the_client_when_creating_the_subscription-AlarmNotification: + parameters: + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + post: + description: > + The POST method notifies a VNF alarm or that the alarm list has been + rebuilt. The API consumer shall have + + previously created an "Individual subscription" resource with a matching + filter. See clause 7.4.6.3.1. + parameters: + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/AlarmNotification' + responses: + '204': + $ref: '#/components/responses/AlarmNotification.Post.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + get: + description: > + The GET method allows the API producer to test the notification endpoint + that is provided by the + + API consumer, e.g. during subscription. See clause 7.4.6.3.2. + responses: + '204': + $ref: '#/components/responses/AlarmNotification.Get.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /URI_is_provided_by_the_client_when_creating_the_subscription-AlarmClearedNotification: + parameters: + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + post: + description: > + The POST method notifies a VNF alarm or that the alarm list has been + rebuilt. The API consumer shall have + + previously created an "Individual subscription" resource with a matching + filter. See clause 7.4.6.3.1. + parameters: + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/AlarmClearedNotification' + responses: + '204': + $ref: '#/components/responses/AlarmClearedNotification.Post.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + get: + description: > + The GET method allows the API producer to test the notification endpoint + that is provided by the + + API consumer, e.g. during subscription. See clause 7.4.6.3.2. + responses: + '204': + $ref: '#/components/responses/AlarmClearedNotification.Get.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /URI_is_provided_by_the_client_when_creating_the_subscription-AlarmListRebuiltNotification: + parameters: + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + post: + description: > + The POST method notifies a VNF alarm or that the alarm list has been + rebuilt. The API consumer shall have + + previously created an "Individual subscription" resource with a matching + filter. See clause 7.4.6.3.1. + parameters: + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/AlarmListRebuiltNotification' + responses: + '204': + $ref: '#/components/responses/AlarmListRebuiltNotification.Post.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + get: + description: > + The GET method allows the API producer to test the notification endpoint + that is provided by the + + API consumer, e.g. during subscription. See clause 7.4.6.3.2. + responses: + '204': + $ref: '#/components/responses/AlarmListRebuiltNotification.Get.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + requestBodies: + AlarmNotification: + description: Information of a VNF alarm. + content: + application/json: + schema: + description: > + This type represents an alarm notification about VNF faults. This + notification shall be triggered by the VNFM when: * An alarm has + been created. * An alarm has been updated, e.g. if the severity of + the alarm has + changed. + type: object + required: + - id + - notificationType + - subscriptionId + - timeStamp + - alarm + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall be + set to "AlarmNotification" for this notification type. + type: string + enum: + - AlarmNotification + subscriptionId: + description: | + An identifier with the intention of being globally unique. + type: string + timeStamp: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + alarm: + description: > + The alarm data type encapsulates information about an alarm. + + NOTE 1: For an alarm about upcoming impact due to NFVI + operation and maintenance (i.e. the attribute + "faultType" has the value "NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE"), the attribute + "rootCauseFaultyResource" indicates a resource to be impacted. Further information on the upcoming + impact (e.g. group of impacted resources, time of impact) is provided in the attribute "faultDetails". + NOTE 2: When alarms are due to upcoming NFVI operation and + maintenance (i.e. the attribute "faultType" has the + value "NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE"), the attribute "faultDetails" shall include + information about the anticipated time of the maintenance. See provisions under the present table. + + If the attribute "faultType" has the value + "NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE", the following + provisions apply for the values of the attribute + "faultDetails" related to changes in the state of virtualised + resources: + - One of the entries in the array shall provide information about the anticipated time of maintenance in the + following format: "anticipatedTime=$time", wherein "$time" shall be formatted as a "DateTime", as specified + in ETSI GS NFV-SOL 013 [8]. + - One of the entries in the array shall provide identification information about the affinity/anti-affinity + group defined in the VNFD that is associated to the affected virtualised resource indicated by + "rootCauseFaultyResource" in the following format: "affinityOrAntiAffinityGroupId=$group", wherein + "$group" shall be equal to the "affinityOrAntiAffinityGroupId" value in the corresponding "VduProfile" (for a + VNFC/COMPUTE affected resource) or "VirtualLinkProfile" for a VL/NETWORK affected resource) in the + VNFD, which is mapped by the VNFM to the virtualised resource group identifier in the virtualised resource + change notification received by the VNFM from the VIM. + type: object + required: + - id + - managedObjectId + - alarmRaisedTime + - ackState + - perceivedSeverity + - eventTime + - eventType + - probableCause + - isRootCause + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + managedObjectId: + description: | + An identifier with the intention of being globally unique. + type: string + rootCauseFaultyResource: + description: > + This type represents the faulty virtual resources that + have a negative impact on a VNF. + type: object + required: + - faultyResource + - faultyResourceType + properties: + faultyResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the CISM + and shall be absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + faultyResourceType: + description: > + The enumeration FaultyResourceType represents those + types of faulty resource. + type: string + enum: + - COMPUTE + - STORAGE + - NETWORK + alarmRaisedTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + alarmChangedTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + alarmClearedTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + alarmAcknowledgedTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + ackState: + description: > + Acknowledgement state of the alarm. Permitted values: * + UNACKNOWLEDGED * ACKNOWLEDGED. + type: string + enum: + - UNACKNOWLEDGED + - ACKNOWLEDGED + perceivedSeverity: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level + indicates that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a service + affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the existence + of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the + detection of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level + indicates that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the + clearing of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + eventType: + description: > + The enumeration EventType represents those types of events + that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of + this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is + associated with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is associated + with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated + with an equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + faultType: + description: > + Additional information to clarify the type of the fault. + Valid values applicable to specific Alarms are specified + as "Alarm definition identifier" values of the Alarm + applicable to Or-Vnfm reference point, as defined in + clause 7.3 of ETSI GS NFV-IFA 045 [13]. If the alarm is + related to changes in the state of virtualised resources + due to NFVI operation and maintenance, this attribute + shall be set to + "NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE". + type: string + probableCause: + description: > + Information about the probable cause of the fault. Valid + values applicable to specific Alarms are specified as + "Probable cause" values of the Alarm applicable to + Or-Vnfm reference point, as defined in clause 7.3 of ETSI + GS NFV-IFA 045 [13]. If the attribute "faultType" has the + value “NFVI_OAM_VIRTUALISED_RESOURCE_STATE_CHANGE”, the + permitted values are: + - "NFVI_COMPONENT_MAINTENANCE": Maintenance of NFVI components, e.g. + physical maintenance/repair, hypervisor software updates, etc. + - "NFVI_COMPONENT_EVACUATION": Evacuation of physical hosts. + - "NFVI_COMPONENT_OPTIMIZATION": Operation and management of NFVI resources, e.g. + to support energy efficiency or resource usage. + type: string + isRootCause: + description: > + Attribute indicating if this fault is the root for other + correlated alarms. If true, then the alarms listed in the + attribute "correlatedAlarmIds" are caused by this fault. + type: boolean + correlatedAlarmIds: + description: > + List of identifiers of other alarms correlated to this + fault. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + faultDetails: + description: > + Provides additional information about the fault. See notes + 1 and 2. Valid values applicable to specific Alarms are + specified as "Fault details" values of the Alarm + applicable to Or-Vnfm reference point, as defined in + clause 7.3 of ETSI GS NFV-IFA 045 [13]. + type: array + items: + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + objectInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + _links: + description: | + Links to resources related to this notification. + type: object + required: + - subscription + properties: + subscription: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + AlarmClearedNotification: + description: Information of the clearance of a VNF alarm + content: + application/json: + schema: + description: > + This type represents an alarm cleared notification about VNF + faults. The notification shall be triggered by the VNFM when an + alarm has been cleared. + type: object + required: + - id + - notificationType + - subscriptionId + - timeStamp + - alarmId + - alarmClearedTime + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall be + set to "AlarmClearedNotification" for this notification type. + type: string + enum: + - AlarmClearedNotification + subscriptionId: + description: | + An identifier with the intention of being globally unique. + type: string + timeStamp: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + alarmId: + description: | + An identifier with the intention of being globally unique. + type: string + alarmClearedTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + _links: + description: | + Links to resources related to this notification. + type: object + required: + - subscription + - alarm + properties: + subscription: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + alarm: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + AlarmListRebuiltNotification: + description: Information that the alarm list has been rebuilt by the VNFM + content: + application/json: + schema: + description: > + This type represents a notification that the alarm list has been + rebuilt, e.g. if the VNFM detects its storage holding the alarm + list is corrupted. The notification shall be triggered by the VNFM + when the alarm list has been rebuilt, e.g. because the VNFM has + detected that its storage holding the alarm list was corrupted. + type: object + required: + - id + - notificationType + - subscriptionId + - timeStamp + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall be + set to "AlarmListRebuiltNotification" for this notification + type. + type: string + enum: + - AlarmListRebuiltNotification + subscriptionId: + description: | + An identifier with the intention of being globally unique. + type: string + timeStamp: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + _links: + description: | + Links to resources related to this notification. + type: object + required: + - subscription + - alarms + properties: + subscription: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + alarms: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + responses: + AlarmNotification.Post.204: + description: | + 204 NO CONTENT + + Shall be returned when the notification has been delivered successfully. + The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: | + Version of the API used in the response. + style: simple + explode: false + schema: + type: string + AlarmNotification.Get.204: + description: > + 204 NO CONTENT + + + Shall be returned to indicate that the notification endpoint has been + tested successfully. + + The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: | + Version of the API used in the response. + style: simple + explode: false + schema: + type: string + AlarmClearedNotification.Post.204: + description: | + 204 NO CONTENT + + Shall be returned when the notification has been delivered successfully. + The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: | + Version of the API used in the response. + style: simple + explode: false + schema: + type: string + AlarmClearedNotification.Get.204: + description: > + 204 NO CONTENT + + + Shall be returned to indicate that the notification endpoint has been + tested successfully. + + The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: | + Version of the API used in the response. + style: simple + explode: false + schema: + type: string + AlarmListRebuiltNotification.Post.204: + description: | + 204 NO CONTENT + + Shall be returned when the notification has been delivered successfully. + The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: | + Version of the API used in the response. + style: simple + explode: false + schema: + type: string + AlarmListRebuiltNotification.Get.204: + description: > + 204 NO CONTENT + + + Shall be returned to indicate that the notification endpoint has been + tested successfully. + + The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: | + Version of the API used in the response. + style: simple + explode: false + schema: + type: string + diff --git a/v5.3.1/SOL003-VNFIndicator-API.json b/v5.3.1/SOL003-VNFIndicator-API.json new file mode 100644 index 00000000..400f96a1 --- /dev/null +++ b/v5.3.1/SOL003-VNFIndicator-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL003 - VNF Indicator interface","description":"SOL003 - VNF Indicator interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"1.13.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 003 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/vnfind/v1"},{"url":"https://127.0.0.1/vnfind/v1"}],"paths":{"/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/indicators":{"get":{"description":"The GET method queries multiple VNF indicators. See clause 8.4.2.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"$ref":"#/components/parameters/filter_vnf_indicators"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/Indicators.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/indicators/{vnfInstanceId}":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"}],"get":{"description":"The GET method queries multiple VNF indicators related to a VNF instance. See clause 8.4.3.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"$ref":""},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/VnfInstanceIndicators.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/indicators/{vnfInstanceId}/{indicatorId}":{"parameters":[{"$ref":"#/components/parameters/IndicatorId"},{"$ref":"#/components/parameters/VnfInstanceId"}],"get":{"description":"The GET method reads a VNF indicator. See clause 8.4.4.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/VnfInstanceIndividualIndicator.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/subscriptions":{"parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"post":{"description":"The POST method creates a new subscription. See clause 8.4.5.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/VnfIndicatorSubscriptionRequest"},"responses":{"201":{"$ref":"#/components/responses/Subscriptions.Post.201"},"303":{"$ref":"#/components/responses/Subscriptions.Post.303"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/Subscriptions.Post.422"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"get":{"description":"The GET method queries the list of active subscriptions of the functional block that invokes the method.\nIt can be used e.g. for resynchronization after error situations. See clause 8.4.5.3.2.\n","parameters":[{"$ref":"#/components/parameters/filter_subscriptions"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/Subscriptions.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/indicators/subscriptions/{subscriptionId}":{"parameters":[{"$ref":"#/components/parameters/SubscriptionId"},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"get":{"description":"The GET method reads an individual subscription. See clause 8.4.6.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualSubscription.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"The DELETE method terminates an individual subscription. See clause 8.4.6.3.5.\n","responses":{"204":{"$ref":"#/components/responses/IndividualSubscription.Delete.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"parameters":{"filter_vnf_indicators":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part of the URI query string. The NFVO may supply this parameter. All attribute names that appear in the VnfIndicator data type and in data types referenced from it shall be supported by the VNFM in the filter expression.\n","in":"query","required":false,"schema":{"type":"string"}},"filter_vnf_indicators_related_to_vnf_instance":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part of the URI query string. The NFVO may supply this parameter. All attribute names that appear in the VnfIndicator data type and in data types referenced from it shall be supported by the VNFM in the filter expression.\n","in":"query","required":false,"schema":{"type":"string"}},"filter_subscriptions":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part of the URI query string. The NFVO may supply this parameter. All attribute names that appear in the VnfIndicatorSubscription data type and in data types referenced from it shall be supported by the VNFM in the filter expression.\n","in":"query","required":false,"schema":{"type":"string"}},"VnfInstanceId":{"name":"vnfInstanceId","in":"path","description":"Identifier of the VNF instance to which the VNF indicator applies.\nThis identifier can be retrieved from the resource referenced by the\n\"Location\" HTTP header in the response to a POST request creating a\nnew \"Individual VNF instance\" resource. It can also be retrieved from the \"id\"\nattribute in the message content of that response.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"IndicatorId":{"name":"indicatorId","in":"path","description":"Identifier of the VNF indicator.\nThis identifier can be retrieved from the resource referenced by the\nmessage content in the response to a POST request creating a new \"Individual VNF\ninstance\" resource.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"SubscriptionId":{"name":"subscriptionId","in":"path","description":"Identifier of this subscription.\nThis identifier can be retrieved from the resource referenced by the\n\"Location\" HTTP header in the response to a POST request creating a\nnew \"Individual subscription\" resource. It can also be retrieved from the \"id\"\nattribute in the message content of that response.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}}},"requestBodies":{"VnfIndicatorSubscriptionRequest":{"description":"Details of the subscription to be created.","content":{"application/json":{"schema":{"description":"This type represents a subscription request related to VNF indicator value change notifications.\n","type":"object","required":["callbackUri"],"properties":{"filter":{"description":"This type represents a subscription filter for notifications related to VNF indicators.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdId"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tVnfIndicatorValueChangeNotification -\tSupportedIndicatorsChangeNotification See note.\n","type":"string","enum":["VnfIndicatorValueChangeNotification","SupportedIndicatorsChangeNotification"]},"indicatorIds":{"description":"Match particular VNF indicator identifiers.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE 1 : The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between\n subscriptions. The value of clientPassword should be generated by a random process.\n* NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT which uses mutual authentication based on X.509 certificates, this mode which uses client password to authenticate may be used in the access token request\n toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations\n (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details.\n* NOTE 3: The following values that were included up to version 3.4.1 of the present document have been removed: \"BASIC\" (to signal the use of the basic HTTP authentication) has been removed because it is insecure.\n \"TLS_CERT\" to signal an alternative non-token based authorization method using TLS certificates has been\n removed because the method is no longer supported.\n* NOTE 4: The client certificate is established by means outside the scope of the present document.\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values (see note 3): * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use\n an OAuth 2.0 token, obtained using the client\n credentials grant type after authenticating\n using client identifier and client password\n towards the token endpoint.\n* OAUTH2_CLIENT_CERT: In every HTTP request to the notification endpoint, use an\n OAuth 2.0 token, obtained using the client\n credentials grant type after mutually\n authenticating using client identifier and X.509\n certificates towards the token endpoint.\n","type":"array","items":{"type":"string","enum":["OAUTH2_CLIENT_CREDENTIALS","OAUTH2_CLIENT_CERT"]}},"paramsOauth2ClientCert":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CERT.\nShall be present if authType is \"OAUTH2_CLIENT_CERT\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\n","type":"object","required":["clientId","certificateRef","tokenEndpoint"],"properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint.\n","type":"string"},"certificateRef":{"description":"Fingerprint of the client certificate. The hash function shall use SHA256 or higher. See note 4.\n","type":"string","required":["type","value"],"properties":{"type":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"value":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS.\nShall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\nSee note 2.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"clientPassword":{"description":"Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true}},"responses":{"Indicators.Get.200":{"description":"200 OK\n\nShall be returned when information about zero or more VNF indicators has been queried successfully.\nThe response body shall contain in an array the representations of all VNF indicators that match\nthe attribute filter, i.e. zero or more representations of VNF indicators as defined in clause 8.5.2.2.\nIf the \"filter\" URI parameter was supplied in the request, the data in the response body shall have\nbeen transformed according to the rules specified in clause 5.2.2 of ETSI GS NFV-SOL 013.\nIf the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013\nfor this resource, inclusion of the Link HTTP header in this response shall follow the provisions\nin clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a VNF indicator value.\nNOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n","type":"object","required":["id","value","vnfInstanceId","_links"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Human readable name of the indicator. Shall be present if defined in the VNFD.\n","type":"string"},"value":{"description":"Provides the value of the indicator. The value format is defined in the VNFD. See note.\n","type":"object"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcInstanceIds":{"description":"The vnfcInstanceIds attribute is optionally present. If present, it contains the list of identifiers of VNFC instances which provide the indicator value(s).\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self","vnfInstance"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"VnfInstanceIndicators.Get.200":{"description":"200 OK\n\nShall be returned when information about zero or more VNF indicators has been queried successfully.\nThe response body shall contain in an array the representations of all VNF indicators that are related\nto the particular VNF instance and that match the attribute filter, i.e. zero or more representations\nof VNF indicators as defined in clause 8.5.2.2.\nIf the \"filter\" URI parameter was supplied in the request, the data in the response body shall have been\ntransformed according to the rules specified in clause 5.2.2 of ETSI GS NFV-SOL 013.\nIf the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013\nfor this resource, inclusion of the Link HTTP header in this response shall follow the provisions\nin clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a VNF indicator value.\nNOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n","type":"object","required":["id","value","vnfInstanceId","_links"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Human readable name of the indicator. Shall be present if defined in the VNFD.\n","type":"string"},"value":{"description":"Provides the value of the indicator. The value format is defined in the VNFD. See note.\n","type":"object"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcInstanceIds":{"description":"The vnfcInstanceIds attribute is optionally present. If present, it contains the list of identifiers of VNFC instances which provide the indicator value(s).\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self","vnfInstance"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"VnfInstanceIndividualIndicator.Get.200":{"description":"200 OK\nShall be returned when the VNF indicator has been read successfully.\nThe response body shall contain the representation of the VNF indicator.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a VNF indicator value.\nNOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n","type":"object","required":["id","value","vnfInstanceId","_links"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Human readable name of the indicator. Shall be present if defined in the VNFD.\n","type":"string"},"value":{"description":"Provides the value of the indicator. The value format is defined in the VNFD. See note.\n","type":"object"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcInstanceIds":{"description":"The vnfcInstanceIds attribute is optionally present. If present, it contains the list of identifiers of VNFC instances which provide the indicator value(s).\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self","vnfInstance"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"Subscriptions.Post.201":{"description":"201 CREATED\n\nShall be returned when the subscription has been created successfully.\nThe response body shall contain a representation of the created \"Individual subscription\" resource.\nThe HTTP response shall include a \"Location\" HTTP header that points to the created resource.\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a subscription related to notifications about VNF indicator value changes.\n","type":"object","required":["id","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter for notifications related to VNF indicators.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdId"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tVnfIndicatorValueChangeNotification -\tSupportedIndicatorsChangeNotification See note.\n","type":"string","enum":["VnfIndicatorValueChangeNotification","SupportedIndicatorsChangeNotification"]},"indicatorIds":{"description":"Match particular VNF indicator identifiers.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}}}},"callbackUri":{"description":"The URI of the endpoint to send the notification to.\n","type":"string","format":"url"},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"Subscriptions.Post.303":{"description":"303 See Other\n\nShall be returned when a subscription with\nthe same callback URI and the same filter\nalready exists and the policy of the VNFM\nis to not create redundant subscriptions.\nThe HTTP response shall include a\n\"Location\" HTTP header that contains the\nresource URI of the existing \"Individual\nsubscription\" resource.\nThe response body shall be empty\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"Subscriptions.Post.422":{"description":"422 Unprocessable Content\n\nShall be returned when a subscription with\nthe same callback URI and the same filter\nalready exists and the policy of the VNFM\nis to not create redundant subscriptions.\nThe HTTP response shall include a\n\"Location\" HTTP header that contains the\nresource URI of the existing \"Individual\nsubscription\" resource.\nThe response body shall be empty\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"Subscriptions.Get.200":{"description":"200 OK\n\nShall be returned when the list of subscriptions has been queried successfully.\nThe response body shall contain in an array the representations of all active\nsubscriptions of the functional block that invokes the method which match the attribute filter,\ni.e. zero or more representations of VNF indicator subscriptions as defined in clause 8.5.2.4.\nIf the \"filter\" URI parameter was supplied in the request, the data in the response body shall\nhave been transformed according to the rules specified in clause 5.2.2 of ETSI GS NFV-SOL 013.\nIf the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013\nfor this resource, inclusion of the Link HTTP header in this response shall follow the provisions\nin clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a subscription related to notifications about VNF indicator value changes.\n","type":"object","required":["id","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter for notifications related to VNF indicators.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdId"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tVnfIndicatorValueChangeNotification -\tSupportedIndicatorsChangeNotification See note.\n","type":"string","enum":["VnfIndicatorValueChangeNotification","SupportedIndicatorsChangeNotification"]},"indicatorIds":{"description":"Match particular VNF indicator identifiers.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}}}},"callbackUri":{"description":"The URI of the endpoint to send the notification to.\n","type":"string","format":"url"},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"IndividualSubscription.Get.200":{"description":"200 OK\n\nShall be returned when information about an individual subscription has been read successfully.\nThe response body shall contain a representation of the \"Individual subscription\" resource.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a subscription related to notifications about VNF indicator value changes.\n","type":"object","required":["id","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter for notifications related to VNF indicators.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdId"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tVnfIndicatorValueChangeNotification -\tSupportedIndicatorsChangeNotification See note.\n","type":"string","enum":["VnfIndicatorValueChangeNotification","SupportedIndicatorsChangeNotification"]},"indicatorIds":{"description":"Match particular VNF indicator identifiers.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}}}},"callbackUri":{"description":"The URI of the endpoint to send the notification to.\n","type":"string","format":"url"},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualSubscription.Delete.204":{"description":"204 NO CONTENT\n\nShall be returned when the \"Individual subscription\" resource has been deleted successfully.\nThe response body shall be empty.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}}}}} diff --git a/v5.3.1/SOL003-VNFIndicator-API.yaml b/v5.3.1/SOL003-VNFIndicator-API.yaml new file mode 100644 index 00000000..9522d32e --- /dev/null +++ b/v5.3.1/SOL003-VNFIndicator-API.yaml @@ -0,0 +1,10160 @@ +openapi: 3.0.2 +info: + title: SOL003 - VNF Indicator interface + description: | + SOL003 - VNF Indicator interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '1.13.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 003 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf +servers: + - url: 'http://127.0.0.1/vnfind/v1' + - url: 'https://127.0.0.1/vnfind/v1' +paths: + /api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /indicators: + get: + description: | + The GET method queries multiple VNF indicators. See clause 8.4.2.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - $ref: '#/components/parameters/filter_vnf_indicators' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this + resource. + in: query + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/Indicators.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/indicators/{vnfInstanceId}': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + get: + description: > + The GET method queries multiple VNF indicators related to a VNF + instance. See clause 8.4.3.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - $ref: >- + #/components/parameters/filter_vnf_indicators_related_to_vnf_instance + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this + resource. + in: query + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/VnfInstanceIndicators.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/indicators/{vnfInstanceId}/{indicatorId}': + parameters: + - $ref: '#/components/parameters/IndicatorId' + - $ref: '#/components/parameters/VnfInstanceId' + get: + description: | + The GET method reads a VNF indicator. See clause 8.4.4.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/VnfInstanceIndividualIndicator.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /subscriptions: + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + post: + description: | + The POST method creates a new subscription. See clause 8.4.5.3.1. + requestBody: + $ref: '#/components/requestBodies/VnfIndicatorSubscriptionRequest' + responses: + '201': + $ref: '#/components/responses/Subscriptions.Post.201' + '303': + $ref: '#/components/responses/Subscriptions.Post.303' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/Subscriptions.Post.422' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + get: + description: > + The GET method queries the list of active subscriptions of the + functional block that invokes the method. + + It can be used e.g. for resynchronization after error situations. See + clause 8.4.5.3.2. + parameters: + - $ref: '#/components/parameters/filter_subscriptions' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this + resource. + in: query + required: false + schema: + type: string + responses: + '200': + $ref: '#/components/responses/Subscriptions.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/indicators/subscriptions/{subscriptionId}': + parameters: + - $ref: '#/components/parameters/SubscriptionId' + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + get: + description: | + The GET method reads an individual subscription. See clause 8.4.6.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualSubscription.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + The DELETE method terminates an individual subscription. See clause + 8.4.6.3.5. + responses: + '204': + $ref: '#/components/responses/IndividualSubscription.Delete.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + parameters: + filter_vnf_indicators: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part + of the URI query string. The NFVO may supply this parameter. All + attribute names that appear in the VnfIndicator data type and in data + types referenced from it shall be supported by the VNFM in the filter + expression. + in: query + required: false + schema: + type: string + filter_vnf_indicators_related_to_vnf_instance: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part + of the URI query string. The NFVO may supply this parameter. All + attribute names that appear in the VnfIndicator data type and in data + types referenced from it shall be supported by the VNFM in the filter + expression. + in: query + required: false + schema: + type: string + filter_subscriptions: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part + of the URI query string. The NFVO may supply this parameter. All + attribute names that appear in the VnfIndicatorSubscription data type + and in data types referenced from it shall be supported by the VNFM in + the filter expression. + in: query + required: false + schema: + type: string + VnfInstanceId: + name: vnfInstanceId + in: path + description: > + Identifier of the VNF instance to which the VNF indicator applies. + + This identifier can be retrieved from the resource referenced by the + + "Location" HTTP header in the response to a POST request creating a + + new "Individual VNF instance" resource. It can also be retrieved from + the "id" + + attribute in the message content of that response. + required: true + style: simple + explode: false + schema: + type: string + IndicatorId: + name: indicatorId + in: path + description: > + Identifier of the VNF indicator. + + This identifier can be retrieved from the resource referenced by the + + message content in the response to a POST request creating a new + "Individual VNF + + instance" resource. + required: true + style: simple + explode: false + schema: + type: string + SubscriptionId: + name: subscriptionId + in: path + description: > + Identifier of this subscription. + + This identifier can be retrieved from the resource referenced by the + + "Location" HTTP header in the response to a POST request creating a + + new "Individual subscription" resource. It can also be retrieved from + the "id" + + attribute in the message content of that response. + required: true + style: simple + explode: false + schema: + type: string + requestBodies: + VnfIndicatorSubscriptionRequest: + description: Details of the subscription to be created. + content: + application/json: + schema: + description: > + This type represents a subscription request related to VNF + indicator value change notifications. + type: object + required: + - callbackUri + properties: + filter: + description: "This type represents a subscription filter for notifications related to VNF indicators.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdId + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId values + listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, from + one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tVnfIndicatorValueChangeNotification -\tSupportedIndicatorsChangeNotification See note.\n" + type: string + enum: + - VnfIndicatorValueChangeNotification + - SupportedIndicatorsChangeNotification + indicatorIds: + description: | + Match particular VNF indicator identifiers. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + authentication: + description: > + * NOTE 1 : The clientId and clientPassword passed in a + subscription shall not be the same as the clientId and + clientPassword that are used to obtain authorization for API requests. Client credentials may differ between + subscriptions. The value of clientPassword should be generated by a random process. + * NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT + which uses mutual authentication based on X.509 + certificates, this mode which uses client password to authenticate may be used in the access token request + toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations + (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details. + * NOTE 3: The following values that were included up to + version 3.4.1 of the present document have been removed: + "BASIC" (to signal the use of the basic HTTP authentication) has been removed because it is insecure. + "TLS_CERT" to signal an alternative non-token based authorization method using TLS certificates has been + removed because the method is no longer supported. + * NOTE 4: The client certificate is established by means + outside the scope of the present document. + type: object + required: + - authType + properties: + authType: + description: > + Defines the types of Authentication / Authorization which + the API consumer is willing to accept when receiving a + notification. Permitted values (see note 3): * + OAUTH2_CLIENT_CREDENTIALS: In every + HTTP request to the notification endpoint, use + an OAuth 2.0 token, obtained using the client + credentials grant type after authenticating + using client identifier and client password + towards the token endpoint. + * OAUTH2_CLIENT_CERT: In every HTTP + request to the notification endpoint, use an + OAuth 2.0 token, obtained using the client + credentials grant type after mutually + authenticating using client identifier and X.509 + certificates towards the token endpoint. + type: array + items: + type: string + enum: + - OAUTH2_CLIENT_CREDENTIALS + - OAUTH2_CLIENT_CERT + paramsOauth2ClientCert: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CERT. + + Shall be present if authType is "OAUTH2_CLIENT_CERT" and + the contained information has not been provisioned out of + band. + + Shall be absent otherwise. + type: object + required: + - clientId + - certificateRef + - tokenEndpoint + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. + type: string + certificateRef: + description: > + Fingerprint of the client certificate. The hash + function shall use SHA256 or higher. See note 4. + type: string + required: + - type + - value + properties: + type: + description: | + A string defined in IETF RFC 8259. + type: string + value: + description: | + A string defined in IETF RFC 8259. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + paramsOauth2ClientCredentials: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CREDENTIALS. + + Shall be present if authType is + "OAUTH2_CLIENT_CREDENTIALS" and the contained information + has not been provisioned out of band. + + Shall be absent otherwise. + + See note 2. + type: object + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. Shall be present if it has not been + provisioned out of band. See note 1. + type: string + clientPassword: + description: > + Client password to be used in the access token request + of the OAuth 2.0 client credentials grant type. Shall + be present if it has not been provisioned out of band. + See note 1. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + responses: + Indicators.Get.200: + description: > + 200 OK + + + Shall be returned when information about zero or more VNF indicators has + been queried successfully. + + The response body shall contain in an array the representations of all + VNF indicators that match + + the attribute filter, i.e. zero or more representations of VNF + indicators as defined in clause 8.5.2.2. + + If the "filter" URI parameter was supplied in the request, the data in + the response body shall have + + been transformed according to the rules specified in clause 5.2.2 of + ETSI GS NFV-SOL 013. + + If the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 + of ETSI GS NFV-SOL 013 + + for this resource, inclusion of the Link HTTP header in this response + shall follow the provisions + + in clause 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: "This type represents a VNF indicator value.\nNOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n" + type: object + required: + - id + - value + - vnfInstanceId + - _links + properties: + id: + description: | + An identifier that is unique within a VNF descriptor. + type: string + name: + description: > + Human readable name of the indicator. Shall be present if + defined in the VNFD. + type: string + value: + description: > + Provides the value of the indicator. The value format is + defined in the VNFD. See note. + type: object + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfcInstanceIds: + description: > + The vnfcInstanceIds attribute is optionally present. If + present, it contains the list of identifiers of VNFC + instances which provide the indicator value(s). + type: array + items: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + - vnfInstance + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + VnfInstanceIndicators.Get.200: + description: > + 200 OK + + + Shall be returned when information about zero or more VNF indicators has + been queried successfully. + + The response body shall contain in an array the representations of all + VNF indicators that are related + + to the particular VNF instance and that match the attribute filter, i.e. + zero or more representations + + of VNF indicators as defined in clause 8.5.2.2. + + If the "filter" URI parameter was supplied in the request, the data in + the response body shall have been + + transformed according to the rules specified in clause 5.2.2 of ETSI GS + NFV-SOL 013. + + If the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 + of ETSI GS NFV-SOL 013 + + for this resource, inclusion of the Link HTTP header in this response + shall follow the provisions + + in clause 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: "This type represents a VNF indicator value.\nNOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n" + type: object + required: + - id + - value + - vnfInstanceId + - _links + properties: + id: + description: | + An identifier that is unique within a VNF descriptor. + type: string + name: + description: > + Human readable name of the indicator. Shall be present if + defined in the VNFD. + type: string + value: + description: > + Provides the value of the indicator. The value format is + defined in the VNFD. See note. + type: object + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfcInstanceIds: + description: > + The vnfcInstanceIds attribute is optionally present. If + present, it contains the list of identifiers of VNFC + instances which provide the indicator value(s). + type: array + items: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + - vnfInstance + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + VnfInstanceIndividualIndicator.Get.200: + description: | + 200 OK + Shall be returned when the VNF indicator has been read successfully. + The response body shall contain the representation of the VNF indicator. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: "This type represents a VNF indicator value.\nNOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n" + type: object + required: + - id + - value + - vnfInstanceId + - _links + properties: + id: + description: | + An identifier that is unique within a VNF descriptor. + type: string + name: + description: > + Human readable name of the indicator. Shall be present if + defined in the VNFD. + type: string + value: + description: > + Provides the value of the indicator. The value format is + defined in the VNFD. See note. + type: object + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfcInstanceIds: + description: > + The vnfcInstanceIds attribute is optionally present. If + present, it contains the list of identifiers of VNFC + instances which provide the indicator value(s). + type: array + items: + description: > + An identifier that is unique for the respective type within + a VNF instance, but may not be globally unique. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + - vnfInstance + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + Subscriptions.Post.201: + description: > + 201 CREATED + + + Shall be returned when the subscription has been created successfully. + + The response body shall contain a representation of the created + "Individual subscription" resource. + + The HTTP response shall include a "Location" HTTP header that points to + the created resource. + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: > + This type represents a subscription related to notifications + about VNF indicator value changes. + type: object + required: + - id + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: "This type represents a subscription filter for notifications related to VNF indicators.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdId + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId + values listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, + from one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tVnfIndicatorValueChangeNotification -\tSupportedIndicatorsChangeNotification See note.\n" + type: string + enum: + - VnfIndicatorValueChangeNotification + - SupportedIndicatorsChangeNotification + indicatorIds: + description: | + Match particular VNF indicator identifiers. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + callbackUri: + description: | + The URI of the endpoint to send the notification to. + type: string + format: url + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + Subscriptions.Post.303: + description: | + 303 See Other + + Shall be returned when a subscription with + the same callback URI and the same filter + already exists and the policy of the VNFM + is to not create redundant subscriptions. + The HTTP response shall include a + "Location" HTTP header that contains the + resource URI of the existing "Individual + subscription" resource. + The response body shall be empty + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Subscriptions.Post.422: + description: | + 422 Unprocessable Content + + Shall be returned when a subscription with + the same callback URI and the same filter + already exists and the policy of the VNFM + is to not create redundant subscriptions. + The HTTP response shall include a + "Location" HTTP header that contains the + resource URI of the existing "Individual + subscription" resource. + The response body shall be empty + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + Subscriptions.Get.200: + description: > + 200 OK + + + Shall be returned when the list of subscriptions has been queried + successfully. + + The response body shall contain in an array the representations of all + active + + subscriptions of the functional block that invokes the method which + match the attribute filter, + + i.e. zero or more representations of VNF indicator subscriptions as + defined in clause 8.5.2.4. + + If the "filter" URI parameter was supplied in the request, the data in + the response body shall + + have been transformed according to the rules specified in clause 5.2.2 + of ETSI GS NFV-SOL 013. + + If the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 + of ETSI GS NFV-SOL 013 + + for this resource, inclusion of the Link HTTP header in this response + shall follow the provisions + + in clause 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: > + This type represents a subscription related to notifications + about VNF indicator value changes. + type: object + required: + - id + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: "This type represents a subscription filter for notifications related to VNF indicators.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdId + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId + values listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, + from one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tVnfIndicatorValueChangeNotification -\tSupportedIndicatorsChangeNotification See note.\n" + type: string + enum: + - VnfIndicatorValueChangeNotification + - SupportedIndicatorsChangeNotification + indicatorIds: + description: | + Match particular VNF indicator identifiers. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + callbackUri: + description: | + The URI of the endpoint to send the notification to. + type: string + format: url + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualSubscription.Get.200: + description: > + 200 OK + + + Shall be returned when information about an individual subscription has + been read successfully. + + The response body shall contain a representation of the "Individual + subscription" resource. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + This type represents a subscription related to notifications about + VNF indicator value changes. + type: object + required: + - id + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: "This type represents a subscription filter for notifications related to VNF indicators.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names \n of the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdId + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId values + listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, from + one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tVnfIndicatorValueChangeNotification -\tSupportedIndicatorsChangeNotification See note.\n" + type: string + enum: + - VnfIndicatorValueChangeNotification + - SupportedIndicatorsChangeNotification + indicatorIds: + description: | + Match particular VNF indicator identifiers. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + callbackUri: + description: | + The URI of the endpoint to send the notification to. + type: string + format: url + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualSubscription.Delete.204: + description: > + 204 NO CONTENT + + + Shall be returned when the "Individual subscription" resource has been + deleted successfully. + + The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + diff --git a/v5.3.1/SOL003-VNFIndicatorNotification-API.json b/v5.3.1/SOL003-VNFIndicatorNotification-API.json new file mode 100644 index 00000000..ebdc064b --- /dev/null +++ b/v5.3.1/SOL003-VNFIndicatorNotification-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL003 - VNF Indicator Notification interface","description":"SOL003 - VNF Indicator Notification interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"1.13.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 003 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/callback/v1"},{"url":"https://127.0.0.1/callback/v1"}],"paths":{"/URI_is_provided_by_the_client_when_creating_the_subscription-VnfIndicatorValueChangeNotification":{"post":{"description":"The POST method delivers a notification from the API producer to an API consumer. The API consumer shall\nhave previously created an \"Individual subscription\" resource with a matching filter. See clause 8.4.7.3.1.\n","parameters":[{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/AlarmListRebuiltNotification"},"responses":{"204":{"$ref":"#/components/responses/VNFINDNotification.Post.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"get":{"description":"The GET method allows the API producer to test the notification endpoint that is provided by the API consumer,\ne.g. during subscription. See clause 8.4.7.3.2.\n","parameters":[{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"204":{"$ref":"#/components/responses/VNFINDNotification.Get.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"requestBodies":{"AlarmListRebuiltNotification":{"description":"Information that the alarm list has been rebuilt by the VNFM.","content":{"application/json":{"schema":{"oneOf":[{"description":"This type represents a VNF indicator value change notification.\nThe notification shall be triggered by the VNFM when the value of an indicator has changed.\nNOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n","type":"object","required":["id","notificationType","subscriptionId","timeStamp","vnfIndicatorId","value","vnfInstanceId","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"VnfIndicatorValueChangeNotification\" for this notification type.\n","type":"string","enum":["VnfIndicatorValueChangeNotification"]},"subscriptionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfIndicatorId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Human readable name of the VNF indicator. Shall be present if defined in the VNFD.\n","type":"string"},"value":{"description":"Provides the value of the VNF indicator. The value format is defined in the VNFD. See note.\n","type":"object"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"_links":{"description":"Links for this resource.\n","type":"object","required":["vnfInstance","subscription"],"properties":{"vnfInstance":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"subscription":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}},{"description":"This type represents a notification to inform the receiver that the set of indicators supported by a VNF instance has changed.\nThe notification shall be triggered by the VNFM when the set of supported VNF indicators has changed as a side effect of the \"Change current VNF package\" operation. It may be triggered by the VNFM when a VNF has been instantiated.\nNOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n","type":"object","required":["id","notificationType","subscriptionId","timeStamp","vnfInstanceId","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"SupportedIndicatorsChangeNotification\" for this notification type.\n","type":"string","enum":["VnfIndicatorValueChangeNotification"]},"subscriptionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"supportedIndicators":{"description":"Set of VNF indicators supported by the VNF instance.\n","type":"array","items":{"type":"object","required":["vnfIndicatorId"],"properties":{"vnfIndicatorId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Human readable name of the VNF indicator. Shall be present if defined in the VNFD. See note.\n","type":"string"}}}},"_links":{"description":"Links for this resource.\n","type":"object","required":["subscription"],"properties":{"vnfInstance":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"subscription":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}]}}},"required":true}},"responses":{"VNFINDNotification.Post.204":{"description":"204 NO CONTENT\n\nShall be returned when the notification has been delivered successfully.\nThe response body shall be empty.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"VNFINDNotification.Get.204":{"description":"204 NO CONTENT\nShall be returned to indicate that the notification endpoint has been tested successfully.\nThe response body shall be empty.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}}}}} diff --git a/v5.3.1/SOL003-VNFIndicatorNotification-API.yaml b/v5.3.1/SOL003-VNFIndicatorNotification-API.yaml new file mode 100644 index 00000000..0413931a --- /dev/null +++ b/v5.3.1/SOL003-VNFIndicatorNotification-API.yaml @@ -0,0 +1,1670 @@ +openapi: 3.0.2 +info: + title: SOL003 - VNF Indicator Notification interface + description: | + SOL003 - VNF Indicator Notification interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '1.13.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 003 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf +servers: + - url: 'http://127.0.0.1/callback/v1' + - url: 'https://127.0.0.1/callback/v1' +paths: + /URI_is_provided_by_the_client_when_creating_the_subscription-VnfIndicatorValueChangeNotification: + post: + description: > + The POST method delivers a notification from the API producer to an API + consumer. The API consumer shall + + have previously created an "Individual subscription" resource with a + matching filter. See clause 8.4.7.3.1. + parameters: + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/AlarmListRebuiltNotification' + responses: + '204': + $ref: '#/components/responses/VNFINDNotification.Post.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + get: + description: > + The GET method allows the API producer to test the notification endpoint + that is provided by the API consumer, + + e.g. during subscription. See clause 8.4.7.3.2. + parameters: + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + responses: + '204': + $ref: '#/components/responses/VNFINDNotification.Get.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + requestBodies: + AlarmListRebuiltNotification: + description: Information that the alarm list has been rebuilt by the VNFM. + content: + application/json: + schema: + oneOf: + - description: "This type represents a VNF indicator value change notification.\nThe notification shall be triggered by the VNFM when the value of an indicator has changed.\nNOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n" + type: object + required: + - id + - notificationType + - subscriptionId + - timeStamp + - vnfIndicatorId + - value + - vnfInstanceId + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall + be set to "VnfIndicatorValueChangeNotification" for this + notification type. + type: string + enum: + - VnfIndicatorValueChangeNotification + subscriptionId: + description: | + An identifier with the intention of being globally unique. + type: string + timeStamp: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + vnfIndicatorId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + name: + description: > + Human readable name of the VNF indicator. Shall be present + if defined in the VNFD. + type: string + value: + description: > + Provides the value of the VNF indicator. The value format + is defined in the VNFD. See note. + type: object + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - vnfInstance + - subscription + properties: + vnfInstance: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + subscription: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + - description: "This type represents a notification to inform the receiver that the set of indicators supported by a VNF instance has changed.\nThe notification shall be triggered by the VNFM when the set of supported VNF indicators has changed as a side effect of the \"Change current VNF package\" operation. It may be triggered by the VNFM when a VNF has been instantiated.\nNOTE:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n" + type: object + required: + - id + - notificationType + - subscriptionId + - timeStamp + - vnfInstanceId + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall + be set to "SupportedIndicatorsChangeNotification" for + this notification type. + type: string + enum: + - VnfIndicatorValueChangeNotification + subscriptionId: + description: | + An identifier with the intention of being globally unique. + type: string + timeStamp: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + supportedIndicators: + description: | + Set of VNF indicators supported by the VNF instance. + type: array + items: + type: object + required: + - vnfIndicatorId + properties: + vnfIndicatorId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + name: + description: > + Human readable name of the VNF indicator. Shall be + present if defined in the VNFD. See note. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - subscription + properties: + vnfInstance: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + subscription: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + responses: + VNFINDNotification.Post.204: + description: | + 204 NO CONTENT + + Shall be returned when the notification has been delivered successfully. + The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + VNFINDNotification.Get.204: + description: > + 204 NO CONTENT + + Shall be returned to indicate that the notification endpoint has been + tested successfully. + + The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + diff --git a/v5.3.1/SOL003-VNFLifecycleManagement-API.json b/v5.3.1/SOL003-VNFLifecycleManagement-API.json new file mode 100644 index 00000000..83862388 --- /dev/null +++ b/v5.3.1/SOL003-VNFLifecycleManagement-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL003 - VNF Lifecycle Management interface","description":"SOL003 - VNF Lifecycle Management interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"2.16.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 003 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/vnflcm/v2"},{"url":"https://127.0.0.1/vnflcm/v2"}],"paths":{"/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances":{"parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"post":{"description":"The POST method creates a new VNF instance resource based on a VNF package that is onboarded\nand in \"ENABLED\" state. See clause 5.4.2.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/CreateVnfRequest"},"responses":{"201":{"$ref":"#/components/responses/VNFInstances.Post.201"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/VNFInstances.Post.422"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"get":{"description":"The GET method queries information about multiple VNF instances. See clause 5.4.2.3.2.\n","parameters":[{"$ref":"#/components/parameters/filter_vnf_instances"},{"name":"all_fields","description":"Include all complex attributes in the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM shall support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"fields","description":"Complex attributes to be included into the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"exclude_fields","description":"Complex attributes to be excluded from the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"$ref":"#/components/parameters/exclude_default_vnf_instances"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/VNFInstances.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"get":{"description":"The GET method retrieves information about a VNF instance by reading an \"Individual VNF instance\" resource.\nSee clause 5.4.3.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualVnfInstance.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method modifies an \"Individual VNF instance\" resource. See clause 5.4.3.3.4.\n","parameters":[{"name":"If-Unmodified-Since","description":"Used to make the request method conditional on the selected resource representation's last modification date being earlier than or equal to the date provided in the field-value. If the condition is not met, the request fails with a \"412 Precondition Failed\" response.\n","required":false,"in":"header","schema":{"type":"string","format":"date-time"}},{"name":"If-Match","description":"Used to make the request method conditional on the recipient origin server either having at least one current representation of the target resource, when the field-value is \"*\", or having a current representation of the target resource that has an entity-tag matching a member of the list of entity-tags provided in the field-value. If the condition is not met, the request fails with a \"412 Precondition Failed\" response.\n","required":false,"in":"header","schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/VnfInfoModificationRequest"},"responses":{"202":{"$ref":"#/components/responses/IndividualVnfInstance.Patch.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/IndividualVnfInstance.Patch.409"},"412":{"$ref":"#/components/responses/IndividualVnfInstance.Patch.412"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method deletes an \"Individual VNF instance\" resource. See clause 5.4.3.3.5.\n","responses":{"204":{"$ref":"#/components/responses/IndividualVnfInstance.Delete.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/IndividualVnfInstance.Delete.409"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/instantiate":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"}],"post":{"description":"The POST method instantiates a VNF instance. See clause 5.4.4.3.1.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/InstantiateVnfRequest"},"responses":{"202":{"$ref":"#/components/responses/InstantiateVnfInstance.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/InstantiateVnfInstance.Post.409"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/scale":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"}],"post":{"description":"The POST method requests to scale a VNF instance resource incrementally. See clause 5.4.5.3.1.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/ScaleVnfRequest"},"responses":{"202":{"$ref":"#/components/responses/ScaleVnfInstance.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/ScaleVnfInstance.Post.404"},"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/ScaleVnfInstance.Post.409"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/scale_to_level":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"}],"post":{"description":"The POST method requests to scale a VNF instance resource to a target level. See clause 5.4.6.3.1.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/ScaleVnfToLevelRequest"},"responses":{"202":{"$ref":"#/components/responses/ScaleToLevelVnfInstance.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/ScaleToLevelVnfInstance.Post.404"},"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/ScaleToLevelVnfInstance.Post.409"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/change_flavour":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"}],"post":{"description":"The POST method changes the deployment flavour of a VNF instance. See clause 5.4.7.3.1.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/ChangeVnfFlavourRequest"},"responses":{"202":{"$ref":"#/components/responses/ChangeFlavourVnfInstance.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/ChangeFlavourVnfInstance.Post.404"},"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/ChangeFlavourVnfInstance.Post.409"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/terminate":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"}],"post":{"description":"The POST method triggers the VNFM to terminate a VNF instance and to request to the VIM the\nrelease of its used virtualised resources. See clause 5.4.8.3.1.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/TerminateVnfRequest"},"responses":{"202":{"$ref":"#/components/responses/TerminateVnfInstance.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/TerminateVnfInstance.Post.409"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/heal":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"}],"post":{"description":"The POST method requests to heal a VNF instance. See clause 5.4.9.3.1.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/HealVnfRequest"},"responses":{"202":{"$ref":"#/components/responses/HealVnfInstance.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/HealVnfInstance.Post.404"},"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/HealVnfInstance.Post.409"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/operate":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"}],"post":{"description":"The POST method changes the operational state of a VNF instance. See clause 5.4.10.3.1.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/OperateVnfRequest"},"responses":{"202":{"$ref":"#/components/responses/OperateVnfInstance.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/OperateVnfInstance.Post.404"},"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/OperateVnfInstance.Post.409"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/change_ext_conn":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"}],"post":{"description":"The POST method changes the external connectivity of a VNF instance. See clause 5.4.11.3.1.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/ChangeExtVnfConnectivityRequest"},"responses":{"202":{"$ref":"#/components/responses/ChangeExtConnVnfInstance.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/ChangeExtConnVnfInstance.Post.409"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/change_vnfpkg":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"}],"post":{"description":"The POST method changes the current VNF package on which the VNF instance is based. See clause 5.4.11a.3.1.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/ChangeCurrentVnfPkgRequest"},"responses":{"202":{"$ref":"#/components/responses/ChangeVnfpkgVnfInstance.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/ChangeVnfpkgVnfInstance.Post.409"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_lcm_op_occs":{"get":{"description":"The API consumer can use this method to query status information about multiple VNF lifecycle management\noperation occurrences. See clause 5.4.12.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"$ref":"#/components/parameters/filter_vnf_lcm_op_occs"},{"name":"all_fields","description":"Include all complex attributes in the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM shall support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"fields","description":"Complex attributes to be included into the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"exclude_fields","description":"Complex attributes to be excluded from the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"$ref":"#/components/parameters/exclude_default_vnf_lcm_op_occs"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/VnfLcmOpOccs.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_lcm_op_occs/{vnfLcmOpOccId}":{"parameters":[{"$ref":"#/components/parameters/VnfLcmOpOccId"}],"get":{"description":"The API consumer can use this method to retrieve status information about a VNF lifecycle management operation\noccurrence by reading an \"Individual VNF LCM operation occurrence\" resource. See clause 5.4.13.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualVnfLcmOpOcc.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_lcm_op_occs/{vnfLcmOpOccId}/retry":{"parameters":[{"$ref":"#/components/parameters/VnfLcmOpOccId"}],"post":{"description":"The POST method initiates retrying a VNF lifecycle operation if that operation has experienced a temporary\nfailure, i.e. the related \"Individual VNF LCM operation occurrence\" resource is in \"FAILED_TEMP\" state.\nSee clause 5.4.14.3.1.\n","parameters":[{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"202":{"$ref":"#/components/responses/RetryVnfLcmOpOcc.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/RetryVnfLcmOpOcc.Post.404"},"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/RetryVnfLcmOpOcc.Post.409"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_lcm_op_occs/{vnfLcmOpOccId}/rollback":{"parameters":[{"$ref":"#/components/parameters/VnfLcmOpOccId"}],"post":{"description":"The POST method initiates rolling back a VNF lifecycle operation if that operation has experienced a temporary\nfailure, i.e. the related \"Individual VNF LCM operation occurrence\" resource is in \"FAILED_TEMP\" state.\nSee clause 5.4.15.3.1.\n","parameters":[{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"202":{"$ref":"#/components/responses/RollbackVnfLcmOpOcc.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/RollbackVnfLcmOpOcc.Post.404"},"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/RollbackVnfLcmOpOcc.Post.409"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_lcm_op_occs/{vnfLcmOpOccId}/fail":{"parameters":[{"$ref":"#/components/parameters/VnfLcmOpOccId"}],"post":{"description":"The POST method marks a VNF lifecycle management operation occurrence as \"finally failed\" if that operation\noccurrence is in \"FAILED_TEMP\" state. See clause 5.4.16.3.1.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/FailVnfLcmOpOcc.Post.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/FailVnfLcmOpOcc.Post.404"},"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/FailVnfLcmOpOcc.Post.409"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_lcm_op_occs/{vnfLcmOpOccId}/cancel":{"parameters":[{"$ref":"#/components/parameters/VnfLcmOpOccId"}],"post":{"description":"The POST method initiates cancelling an ongoing VNF lifecycle operation while it is being executed or rolled\nback, i.e. the related \"Individual VNF LCM operation occurrence\" resource is either in \"STARTING\" or\n\"PROCESSING\" or \"ROLLING_BACK\" state. See clause 5.4.17.3.1.\n","parameters":[{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"202":{"$ref":"#/components/responses/CancelVnfLcmOpOcc.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/CancelVnfLcmOpOcc.Post.404"},"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/CancelVnfLcmOpOcc.Post.409"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/subscriptions":{"parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"post":{"description":"The POST method creates a new subscription. See clause 5.4.18.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/LccnSubscriptionRequest"},"responses":{"201":{"$ref":"#/components/responses/Subscriptions.Post.201"},"303":{"$ref":"#/components/responses/Subscriptions.Post.303"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/Subscriptions.Post.422"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"get":{"description":"The GET method queries the list of active subscriptions of the functional block that invokes the method.\nIt can be used e.g. for resynchronization after error situations. See clause 5.4.18.3.2.\n","parameters":[{"$ref":"#/components/parameters/filter_subscriptions"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/Subscriptions.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/subscriptions/{subscriptionId}":{"parameters":[{"$ref":"#/components/parameters/SubscriptionId"},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"get":{"description":"The GET method retrieves information about a subscription by reading an \"Individual subscription\" resource.\nSee clause 5.4.19.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualSubscription.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"The DELETE method terminates an individual subscription. See clause 5.4.19.3.5.\n","responses":{"204":{"$ref":"#/components/responses/IndividualSubscription.Delete.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/create_snapshot":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"}],"post":{"description":"The POST method requests taking a snapshot a VNF instance and populating a previously created VNF snapshot\nresource (refer to clause 5.4.23.3.1) with the snapshot content. See clause 5.4.21.3.1.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/CreateVnfSnapshotRequest"},"responses":{"202":{"$ref":"#/components/responses/CreateVnfSnapshotTask.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/CreateVnfSnapshotTask.Post.404"},"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/CreateVnfSnapshotTask.Post.409"},"422":{"$ref":"#/components/responses/CreateVnfSnapshotTask.Post.422"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/revert_to_snapshot":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId"}],"post":{"description":"The POST method requests reverting a VNF instance to a VNF snapshot. See clause 5.4.22.3.1.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/RevertToVnfSnapshotRequest"},"responses":{"202":{"$ref":"#/components/responses/RevertToVnfSnapshotTask.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/RevertToVnfSnapshotTask.Post.404"},"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/RevertToVnfSnapshotTask.Post.409"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_snapshots":{"parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"post":{"description":"The POST method creates a new \"Individual VNF snapshot\" resource. See clause 5.4.23.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/CreateVnfSnapshotInfoRequest"},"responses":{"201":{"$ref":"#/components/responses/VnfSnapshots.Post.201"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"get":{"description":"The GET method queries information about multiple VNF snapshots. This method shall follow the provisions specified in the tables 5.4.23.3.2-1 and 5.4.23.3.2-2 for URI query parameters, request and response data structures, and response codes.\n","parameters":[{"$ref":"#/components/parameters/filter_vnf_snapshots"},{"name":"all_fields","description":"Include all complex attributes in the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM shall support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"fields","description":"Complex attributes to be included into the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"exclude_fields","description":"Complex attributes to be excluded from the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"$ref":"#/components/parameters/exclude_default_vnf_snapshots"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/VnfSnapshots.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_snapshots/{vnfSnapshotInfoId}":{"parameters":[{"$ref":"#/components/parameters/VnfSnapshotInfoId"},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"get":{"description":"The GET method retrieves information about a VNF snapshot by reading an \"Individual VNF snapshot\" resource.\nSee clause 5.4.24.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualVnfSnapshot.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method modifies an \"Individual VNF snapshot\" resource. See clause 5.4.24.3.4.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"If-Unmodified-Since","description":"Used to make the request method conditional on the selected resource representation's last modification date being earlier than or equal to the date provided in the field-value. If the condition is not met, the request fails with a \"412 Precondition Failed\" response.\n","required":false,"in":"header","schema":{"type":"string","format":"date-time"}},{"name":"If-Match","description":"Used to make the request method conditional on the recipient origin server either having at least one current representation of the target resource, when the field-value is \"*\", or having a current representation of the target resource that has an entity-tag matching a member of the list of entity-tags provided in the field-value. If the condition is not met, the request fails with a \"412 Precondition Failed\" response.\n","required":false,"in":"header","schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/VnfSnapshotInfoModificationRequest"},"responses":{"200":{"$ref":"#/components/responses/IndividualVnfSnapshot.Patch.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/IndividualVnfSnapshot.Patch.409"},"412":{"$ref":"#/components/responses/IndividualVnfSnapshot.Patch.412"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method deletes an \"Individual VNF snapshot\" resource and the associated VNF snapshot information\nmanaged by the VNFM, and any resource associated to the VNF snapshot managed by the VIM. See clause 5.4.24.3.5.\n","responses":{"204":{"$ref":"#/components/responses/IndividualVnfSnapshot.Delete.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/IndividualVnfSnapshot.Delete.409"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_snapshots/{vnfSnapshotInfoId}/vnf_state_snapshot":{"parameters":[{"$ref":"#/components/parameters/VnfSnapshotInfoId"},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"get":{"description":"The GET method fetches the content of the VNF state snapshot.\nThis method shall follow the provisions specified in the tables 5.4.25.3.2-1 and 5.4.25.3.2-2\nfor URI query parameters, request and response data structures, and response codes.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"$ref":"#/components/parameters/Range"}],"responses":{"200":{"$ref":"#/components/responses/IndividualVnfSnapshotState.Get.200"},"206":{"$ref":"#/components/responses/IndividualVnfSnapshotState.Get.206"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/IndividualVnfSnapshotState.Get.409"},"416":{"$ref":"#/components/responses/IndividualVnfSnapshotState.Get.416"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_instances/{vnfInstanceId}/select_depl_mods":{"parameters":[{"$ref":"#/components/parameters/VnfInstanceId_1"},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"post":{"description":"The POST method requests to select deployable modules of a VNF instance and therefore to instantiate or terminate\nVNFC instances according to the selected deployable modules.\n","requestBody":{"$ref":"#/components/requestBodies/SelectVnfDeployableModulesRequest"},"responses":{"202":{"$ref":"#/components/responses/Selectdeployablemodules.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"409 CONFLICT\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"parameters":{"filter_vnf_instances":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part of the URI query string. The NFVO may supply this parameter. All attribute names that appear in the VnfInstance and in data types referenced from it shall be supported by the VNFM in the filter expression.\n","in":"query","required":false,"schema":{"type":"string"}},"exclude_default_vnf_instances":{"name":"exclude_default","in":"query","description":"Indicates to exclude the following complex attributes from the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM shall support this parameter. The following attributes shall be excluded from the VnfInstance structure in the response body if this parameter is provided, or none of the parameters \"all_fields\", \"fields\", \"exclude_fields\", \"exclude_default\" are provided: - vnfConfigurableProperties\n - vimConnectionInfo\n - instantiatedVnfInfo\n - metadata\n - extensions","required":false,"schema":{"type":"string"}},"filter_vnf_lcm_op_occs":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part of the URI query string. The NFVO may supply this parameter. All attribute names that appear in the VnfLcmOpOcc and in data types referenced from it shall be supported by the VNFM in the filter expression.\n","in":"query","required":false,"schema":{"type":"string"}},"exclude_default_vnf_lcm_op_occs":{"name":"exclude_default","in":"query","description":"Indicates to exclude the following complex attributes from the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM shall support this parameter. The following attributes shall be excluded from the VnfLcmOpOcc structure in the response body if this parameter is provided, or none of the parameters \"all_fields,\" \"fields\", \"exclude_fields\", \"exclude_default\" are provided: - operationParams\n - error\n - resourceChanges\n - changedInfo\n - changedExtConnectivity\n - lcmCoordinations\n - modificationsTriggeredByVnfPkgChange\n - warnings","required":false,"schema":{"type":"string"}},"filter_subscriptions":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part of the URI query string. The NFVO may supply this parameter. All attribute names that appear in the LccnSubscription and in data types referenced from it shall be supported by the VNFM in the filter expression.\n","in":"query","required":false,"schema":{"type":"string"}},"filter_vnf_snapshots":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part of the URI query string. The NFVO may supply this parameter. All attribute names that appear in the VnfSnapshot and in data types referenced from it shall be supported by the VNFM in the filter expression.\n","in":"query","required":false,"schema":{"type":"string"}},"exclude_default_vnf_snapshots":{"name":"exclude_default","in":"query","description":"Indicates to exclude the following complex attributes from the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM shall support this parameter. The following attributes shall be excluded from the VnfSnapshot structure in the response body if this parameter is provided, or none of the parameters \"all_fields,\" \"fields\", \"exclude_fields\", \"exclude_default\" are provided: - vnfInstance\n - vnfcSnapshots","required":false,"schema":{"type":"string"}},"VnfInstanceId":{"name":"vnfInstanceId","in":"path","description":"Identifier of the VNF instance for the VNF snapshot to be reverted to. This identifier can be retrieved from the resource\nreferenced by the \"Location\" HTTP header in the response to a POST request creating a new \"Individual VNF instance\" resource.\nIt can also be retrieved from the \"id\" attribute in the message content of that response.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"VnfLcmOpOccId":{"name":"vnfLcmOpOccId","in":"path","description":"Identifier of a VNF lifecycle management operation occurrence. This identifier can be retrieved from the resource\nreferenced by the \"Location\" HTTP header in the response to a PATCH or POST request triggering a VNF LCM operation.\nIt can also be retrieved from the \"vnfLcmOpOccId\" attribute in the VnfLcmOperationOccurrenceNotification.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"SubscriptionId":{"name":"subscriptionId","in":"path","description":"Identifier of this subscription. This identifier can be retrieved from the resource referenced by the \"Location\"\nHTTP header in the response to a POST request creating a new subscription resource. It can also be retrieved from\nthe \"id\" attribute in the message content of that response.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"VnfSnapshotInfoId":{"name":"vnfSnapshotInfoId","in":"path","description":"Identifier of the \"Individual VNF snapshot\" resource. This identifier can be retrieved\nfrom the resource referenced by the \"Location\" HTTP header in the response to a POST request\ncreating a new VNF snapshot resource. It can also be retrieved from the \"id\" attribute in\nthe message content of that response.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"VnfInstanceId_1":{"name":"vnfInstanceId","in":"path","description":"Identifier of the VNF instance of which the deployable modules are requested to be selected. See note.\n\nNOTE: This identifier can be retrieved from the resource referenced by the \"Location\" HTTP header\nin the response to a POST request creating a new \"Individual VNF instance\" resource. It can\nalso be retrieved from the \"id\" attribute in the message content of that response.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"Range":{"name":"Range","in":"header","description":"The request may contain a \"Range\" HTTP header to obtain single\nrange of bytes from a VNF state snapshot file. This can be used to\ncontinue an aborted transmission.\nIf the \"Range\" header is present in the request and the VNFM\ndoes not support responding to range requests with a 206\nresponse, it shall return a 200 OK response instead.\n","schema":{"type":"string"}}},"requestBodies":{"CreateVnfRequest":{"description":"The VNF creation parameters","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Create VNF identifier\" operation.\n","type":"object","required":["vnfdId"],"properties":{"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceName":{"description":"Human-readable name of the VNF instance to be created.\n","type":"string"},"vnfInstanceDescription":{"description":"Human-readable description of the VNF instance to be created.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateConfigurationData":{"description":"This type provides input information related to certificate management.\nETSI GS NFV-SOL 009 [i.18] specifies the means to discover the applicable certificate management mode of VNFM and configure into the NFVO applicable certificate management mode via the \"NFV-MANO Configuration and Information Management\" interface\n","type":"object","properties":{"overridingCertificateProfiles":{"description":"Overriding certificate profile. This overrides the certificateBaseProfile provided in the VNFD, and the CA and CMF can additionally override aspects of this certificateBaseProfile at later point in the VNF lifecycle if necessary to meet operator security policy.\n","type":"array","items":{"description":"NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\nThis type provides input information to override certificate base profile for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"description":"Issuer of certificates. See note.","type":"string"},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to the subject of the certificate.\nNOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of the certification target subject FQDN. Can be set empty when this certificate is used for encrypted communication using IP address. See note.\n","type":"string"},"organization":{"description":"Information of the certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of the certification target subject Country. See note.","type":"string"},"state":{"description":"Information of the certification target subject State. See note.","type":"string"},"locality":{"description":"Information of the certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of the certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"description":"Basic constraints of certificates. See note.","type":"string"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [14], clause 7.1.19.4). See note.\n","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}}},"securityPolicy":{"description":"Security policy to be satisfied for the certificate.\n","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"number"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"number"}}}},"cmfData":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["endPoint","supportedProtocols"],"properties":{"endPoint":{"description":"End point of CMF instance.","type":"object","properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocols":{"description":"Supported protocols by CMF instance.","type":"array","items":{"description":"Supported protocol by CMF instance.","type":"string","enum":["CMP","CMPv2","EST","SCEP"]}}}}}}}}}},"required":true},"VnfInfoModificationRequest":{"description":"Parameters for the VNF modification, as defined in clause 5.5.2.12.\n","content":{"application/merge-patch+json":{"schema":{"description":"This type represents attribute modifications for an \"Individual VNF instance\" resource, i.e. modifications to a resource representation based on the \"VnfInstance\" data type.\n","type":"object","properties":{"vnfInstanceName":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfInstanceDescription":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vimConnectionInfo":{"description":"Modifications of the \"vimConnectionInfo\" attribute. If present, these modifications shall be applied according to the rules of JSON Merge Patch (see IETF RFC 7396 [5]).\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}}}},"required":true},"InstantiateVnfRequest":{"description":"Parameters for the VNF instantiation.","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Instantiate VNF\" operation.\n* NOTE 1:\tThe indication of externally-managed internal VLs is needed in case \n networks have been pre-configured for use with certain VNFs, for instance \n to ensure that these networks have certain properties such as security or \n acceleration features, or to address particular network topologies. \n The present document assumes that externally-managed internal VLs are \n managed by the NFVO and created towards the VIM.\n* NOTE 2:\tIt is possible to have several ExtManagedVirtualLinkData for the same VNF \n internal VL in case of a multi-site VNF spanning several VIMs. The set of \n ExtManagedVirtualLinkData corresponding to the same VNF internal VL shall \n indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed \n multi-site VL instance (refer to clause 4.4.1.12).\n* NOTE 3: The target size for VNF instantiation may be specified in either instantiationLevelId or targetScaleLevelInfo, but\n not both. If none of the two attributes (instantiationLevelId or targetScaleLevelInfo) are present, the default\n instantiation level as declared in the VNFD shall be used.\n* NOTE 4: If targetScaleLevelInfo is specified, information provided in targetScaleLevelInfo shall be used for instantiating\n scalable constituents of the VNF (e.g, VDUs/VLs). For scaling aspects not specified in targetScaleLevelInfo or\n for the VNF constituents (e.g.,VDUs/VLs) that are not scalable, the default instantiation level as declared in the\n VNFD shall be used for instantiation.\n* NOTE 5: If the referenced instantiationLevel or the targetScaleLevelInfo contain information related to VNFCs that are \n not going to be instantiated due to the selection of deployable modules, the information is stored in the VNFM \n for later use and included in the instantiatedVnfInfo. If none of the attributes is present, the information from the \n defaultInstantiationLevel related to those VNFCs is stored and included in the instantiatedVnfInfo. If, during the \n lifecycle of the VNF, as a result of a change of the selected deployable modules any of those VNFCs is going to \n be instantiated, the stored information determines the number of instances, unless the request that triggered \n the change also contains information about the number of instances.\n","type":"object","required":["flavourId"],"properties":{"flavourId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"instantiationLevelId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"targetScaleLevelInfo":{"description":"This attribute is applicable if VNF supports target scale level instantiation. For each scaling aspect of the current deployment flavour, the attribute specifies the scale level of VNF constituents (e.g., VDU level) to be instantiated. See notes 3, 4, and 5.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"extVirtualLinks":{"description":"Information about external VLs to connect the VNF to, including configuration information for the CPs via which the VNF instance can attach to this VL. The following applies to the \"ExtVirtualLinkData\" information provided in this request, together with the the related overriding information provided in the \"Grant\" structure (see clause 9.5.2.3): Even if the VNF is not instantiated in fully scaled-out state, the API consumer shall provide enough CP configuration records to allow connecting the VNF instance, fully scaled out in all scaling aspects, to the external VLs.\n","type":"array","items":{"description":"This type represents an external VL.\n* NOTE 1:\tA link port is not needed for an external CP instance that exposes a CP in the following cases:\n 1) For a VIP CP directly exposed as an external CP:\n 1.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD.\n 1.2) A dedicated IP address is allocated as VIP address, but the NFVO indicates that no port is needed\n (createExtLinkPort in VnfExtCpConfig set to false).\n 2) For a VIP CP exposed as an external CP via a floating IP address:\n 2.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD, and the VNFC CP\n associated to the VIP CP is also exposed via a floating IP address.\n 3) For a VIRTUAL CP exposed as an external CP.\n 4) For a VNFC CP exposed as an external CP in a secondary container cluster external network or a\n secondary container cluster internal network.\n\n* NOTE 2: An example of the network attachment definition resource when the container infrastructure service\n management is a Kubernetes® instance is a network attachment definition (NAD).\n* NOTE 3: Either \"extCps\" or “extCpsDeletion\" shall be present, but not both.\n","type":"object","required":["id","resourceId"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"extCps":{"description":"External CPs of the VNF to be connected to this external VL. Entries in the list of external CP data that are unchanged need not be supplied if the ExtVirtualLinkData structure is part of a request or response that modifies the external connectivity. See note 3.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}},"extLinkPorts":{"description":"Externally provided link ports to be used to connect external connection points to this external VL. If this attribute is not present, the VNFM shall create the link ports on the external VL except in the cases defined below. See note 1.\n","type":"array","items":{"description":"This type represents an externally provided link port to be used to connect an external connection point to an external VL. * NOTE:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"extNetAttDefResourceData":{"description":"Externally provided network attachment definition resource(s) that provide the specification of the interface to attach external CPs to this external VL. See note 2. It is only applicable if the external VL is realized by a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"This type represents a network attachment definition resource that provides the specification of the interface to be used to connect one or multiple connection points to a secondary container cluster network realizing a VL.\n","type":"object","required":["netAttDefResourceId","resourceHandle"],"properties":{"netAttDefResourceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"extCpsDeletion":{"description":"External CPs of the VNF to be disconnected from this external VL and to be deleted. See note 3.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}}}}},"extManagedVirtualLinks":{"description":"Information about internal VLs that are managed by the NFVO. See note 1 and note 2.\n","type":"array","items":{"description":"This type represents an externally-managed internal VL.\n* NOTE 1: It is only applicable if the externally-managed VL is realized by a secondary container cluster network. It shall not be present otherwise.\n* NOTE 2: A link port is not needed for a VNFC internal connection point connected to a secondary container cluster network.\n* NOTE 3: An example of the network attachment definition resource when the container infrastructure service management is a Kubernetes® instance is a network attachment definition (NAD).\n\n* NOTE 4: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, an instance of intCp need not be included for each VNFC instance as all instances would contain the same \n information. It is sufficient to include one intCp for the related CPD. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version\n* NOTE 5: Both \"vnfLinkPort\" and \"netAttDefResource\" attributes can be provided in a \"ExtManagedVirtualLinkData\" to indicate that a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs\n","type":"object","required":["id","vnfVirtualLinkDescId","resourceId"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"netAttDefResourceData":{"description":"Externally provided network attachment definition resource(s) that provide the specification of the interface to attach VNFC connection points to this externallymanaged VL. See notes 1, 3 and 5.\n","type":"array","items":{"description":"This type represents a network attachment definition resource that provides the specification of the interface to be used to connect one or multiple connection points to a secondary container cluster network realizing a VL.\n","type":"object","required":["netAttDefResourceId","resourceHandle"],"properties":{"netAttDefResourceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"intCp":{"description":"Internal CPs of the VNF to be connected to this externally-managed VL. See note 1 and 4.\n","type":"array","items":{"description":"This type represents input information related to one or more VNF internal CP instances created based on the same CPD.\nNOTE: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the VNF internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall\n belong to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n","type":"object","required":["cpdId","netAttDefResourceId"],"properties":{"cpdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifiers of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the VNF internal CP created from the CPD identified by cpdId to a secondary container cluster network. See note.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfLinkPort":{"description":"Externally provided link ports to be used to connect VNFC connection points to this externally-managed VL on this network resource. If this attribute is not present, the VNFM shall create the link ports on the externally-managed VL. See notes 2 and 5.\n","type":"array","items":{"description":"This type represents an externally provided link port to be used to connect a VNFC connection point to an externally managed VL.\n","type":"object","required":["vnfLinkPortId","resourceHandle"],"properties":{"vnfLinkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"extManagedMultisiteVirtualLinkId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"vimConnectionInfo":{"description":"Information about VIM or CISM connections to be used for managing the resources for the VNF instance, or refer to external/externally-managed virtual links. This attribute shall only be supported and may be present if - the resources for at least one of the VNFCs shall be managed by a VIM and VNF-related resource management in direct mode is applicable. - the resources for at least one of the VNFCs shall be managed by a CISM. The VNFM shall apply the content of this attribute to the \"vimConnectionInfo\" attribute of \"VnfInstance\" according to the rules of JSON Merge Patch (see IETF RFC 7396 [5]).\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"localizationLanguage":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"selectedDeployableModule":{"description":"Identifier of a selected deployable module. Only VNFCs based on VDUs that belong to deployable modules listed in this attribute are requested to be instantiated.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceCapacityDefinition":{"description":"Indicates values for resource capacity related attributes pertaining to a descriptor. Values can only be provided for resource capacity related attributes that have been defined in the VNFD as being configurable. Furthermore, provided values shall be within the allowed values indicated in the VNFD.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes.\nThe tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request.\nAt most one tag can be included when the data type is used in a VNF LCM operation request.\nWhen the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.\n","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced.\n","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute 'type' indicates OSCONTAINER and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource. See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resource property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for this virtual compute descriptor. The value is a numberthat indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) that indicates the valid vaues for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}}}}}},"required":true},"ScaleVnfRequest":{"description":"Parameters for the scale VNF operation.","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Scale VNF\" operation.\n","type":"object","required":["type"],"properties":{"type":{"description":"Indicates the type of the scale operation requested. Permitted values: * SCALE_OUT: adding additional VNFC instances to the VNF to increase capacity\n* SCALE_IN: removing VNFC instances from the VNF in order to release unused capacity.\n* SCALE_VERTICAL: increasing or decreasing the resource capacity of all instances of one or multiple VNFCs.\n","type":"string","enum":["SCALE_OUT","SCALE_IN","SCALE_VERTICAL"]},"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numberOfSteps":{"description":"Number of scaling steps to be executed as part of this Scale VNF operation. It shall be a positive number and the default value shall be 1.\n","type":"integer","default":1},"resourceCapacityDefinition":{"description":"Indicates values for resource capacity related attributes pertaining to a descriptor. The indicated values are absolute (target) values, as opposed to relative (delta) values. Values can only be provided for resource capacity related attributes that have been defined in the VNFD as being configurable. Furthermore, provided values shall be within the allowed values indicated in the VNFD. It shall be present when 'type' indicates SCALE_VERTICAL and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes.\nThe tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request.\nAt most one tag can be included when the data type is used in a VNF LCM operation request.\nWhen the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.\n","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced.\n","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute 'type' indicates OSCONTAINER and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource. See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resource property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for this virtual compute descriptor. The value is a numberthat indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) that indicates the valid vaues for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"required":true},"ScaleVnfToLevelRequest":{"description":"Parameters for the scale VNF to Level operation.","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Scale VNF to Level\" operation.\nNOTE 1:\tEither the instantiationLevelId attribute or the scaleInfo attribute or the powerProfileId attribute shall \n be included, but not multiple of them.\nNOTE 2: If the referenced instantiationLevel, the scaleInfo or powerProfileId attribute contain information related to VNFCs \n that are not going to be instantiated due to the selection of deployable modules, the information is stored in the \n VNFM for later use and included in the instantiatedVnfInfo. If, during the lifecycle of the VNF, as a result of a \n change of the selected deployable modules any of those VNFCs is going to be instantiated, the stored information \n determines the number of instances, unless the request that triggered the change also contains information \n about the number of instances\n","type":"object","anyOf":[{"oneOf":[{"required":["instantiationLevelId"]},{"required":["scaleInfo"]},{"required":["powerProfileId"]}]}],"properties":{"instantiationLevelId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"scaleInfo":{"description":"For each scaling aspect of the current deployment flavour, indicates the target scale level to which the VNF is to be scaled. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"powerProfileId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"required":true},"ChangeVnfFlavourRequest":{"description":"Parameters for the Change VNF Flavour operation.","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Change VNF flavour\" operation.\n* NOTE 1:\tThe indication of externally-managed internal VLs is needed in case networks \n have been pre-configured for use with certain VNFs, for instance to ensure \n that these networks have certain properties such as security or acceleration \n features, or to address particular network topologies. The present document \n assumes that externally-managed internal VLs are managed by the NFVO and created \n towards the VIM.\n* NOTE 2:\tIt is possible to have several ExtManagedVirtualLinkData for the same VNF internal \n VL in case of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkData \n corresponding to the same VNF internal VL shall indicate so by referencing to the same \n VnfVirtualLinkDesc and externally-managed multi-site VL instance (refer to clause 4.4.1.12).\n* NOTE 3: The target size for VNF instantiation may be specified in either instantiationLevelId or targetScaleLevelInfo, but\n not both. If none of the two attributes (instantiationLevelId or targetScaleLevelInfo) are present, the default\n instantiation level as declared in the VNFD shall be used.\n* NOTE 4: If targetScaleLevelInfo is specified, information provided in targetScaleLevelInfo shall be used for instantiating\n scalable constituents of the VNF (e.g, VDUs/VLs). For scaling aspects not specified in targetScaleLevelInfo or\n for the VNF constituents (e.g.,VDUs/VLs) that are not scalable, the default instantiation level as declared in the\n VNFD shall be used for instantiation.\n","type":"object","required":["newFlavourId"],"properties":{"newFlavourId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"instantiationLevelId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"targetScaleLevelInfo":{"description":"This attribute is applicable if VNF supports target scale level instantiation. For each scaling aspect of the current deployment flavour, the attribute specifies the scale level of VNF constituents (e.g., VDU level) to be instantiated. See notes 3 and 4.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"extVirtualLinks":{"description":"Information about external VLs to connect the VNF to, including configuration information for the CPs via which the VNF instance can attach to this VL. Entries in the list of external VLs that are unchanged need not be supplied as part of this request. The following applies to the \"ExtVirtualLinkData\" information provided in this request, together with the related \"ExtVirtualLinkInfo\" information known to the VNFM represented in the \"VnfInstance\" structure (see clause 5.5.2.2) and the related overriding information provided in the \"Grant\" structure (see clause 9.5.2.3): Even if the VNF is not in fully scaled-out state after changing the flavour, the API consumer shall provide enough CP configuration records to allow connecting the VNF instance, fully scaled out in all scaling aspects, to the external VLs.\n","type":"array","items":{"description":"This type represents an external VL.\n* NOTE 1:\tA link port is not needed for an external CP instance that exposes a CP in the following cases:\n 1) For a VIP CP directly exposed as an external CP:\n 1.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD.\n 1.2) A dedicated IP address is allocated as VIP address, but the NFVO indicates that no port is needed\n (createExtLinkPort in VnfExtCpConfig set to false).\n 2) For a VIP CP exposed as an external CP via a floating IP address:\n 2.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD, and the VNFC CP\n associated to the VIP CP is also exposed via a floating IP address.\n 3) For a VIRTUAL CP exposed as an external CP.\n 4) For a VNFC CP exposed as an external CP in a secondary container cluster external network or a\n secondary container cluster internal network.\n\n* NOTE 2: An example of the network attachment definition resource when the container infrastructure service\n management is a Kubernetes® instance is a network attachment definition (NAD).\n* NOTE 3: Either \"extCps\" or “extCpsDeletion\" shall be present, but not both.\n","type":"object","required":["id","resourceId"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"extCps":{"description":"External CPs of the VNF to be connected to this external VL. Entries in the list of external CP data that are unchanged need not be supplied if the ExtVirtualLinkData structure is part of a request or response that modifies the external connectivity. See note 3.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}},"extLinkPorts":{"description":"Externally provided link ports to be used to connect external connection points to this external VL. If this attribute is not present, the VNFM shall create the link ports on the external VL except in the cases defined below. See note 1.\n","type":"array","items":{"description":"This type represents an externally provided link port to be used to connect an external connection point to an external VL. * NOTE:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"extNetAttDefResourceData":{"description":"Externally provided network attachment definition resource(s) that provide the specification of the interface to attach external CPs to this external VL. See note 2. It is only applicable if the external VL is realized by a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"This type represents a network attachment definition resource that provides the specification of the interface to be used to connect one or multiple connection points to a secondary container cluster network realizing a VL.\n","type":"object","required":["netAttDefResourceId","resourceHandle"],"properties":{"netAttDefResourceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"extCpsDeletion":{"description":"External CPs of the VNF to be disconnected from this external VL and to be deleted. See note 3.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}}}}},"extManagedVirtualLinks":{"description":"Information about internal VLs that are managed by the NFVO. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents an externally-managed internal VL.\n* NOTE 1: It is only applicable if the externally-managed VL is realized by a secondary container cluster network. It shall not be present otherwise.\n* NOTE 2: A link port is not needed for a VNFC internal connection point connected to a secondary container cluster network.\n* NOTE 3: An example of the network attachment definition resource when the container infrastructure service management is a Kubernetes® instance is a network attachment definition (NAD).\n\n* NOTE 4: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, an instance of intCp need not be included for each VNFC instance as all instances would contain the same \n information. It is sufficient to include one intCp for the related CPD. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version\n* NOTE 5: Both \"vnfLinkPort\" and \"netAttDefResource\" attributes can be provided in a \"ExtManagedVirtualLinkData\" to indicate that a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs\n","type":"object","required":["id","vnfVirtualLinkDescId","resourceId"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"netAttDefResourceData":{"description":"Externally provided network attachment definition resource(s) that provide the specification of the interface to attach VNFC connection points to this externallymanaged VL. See notes 1, 3 and 5.\n","type":"array","items":{"description":"This type represents a network attachment definition resource that provides the specification of the interface to be used to connect one or multiple connection points to a secondary container cluster network realizing a VL.\n","type":"object","required":["netAttDefResourceId","resourceHandle"],"properties":{"netAttDefResourceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"intCp":{"description":"Internal CPs of the VNF to be connected to this externally-managed VL. See note 1 and 4.\n","type":"array","items":{"description":"This type represents input information related to one or more VNF internal CP instances created based on the same CPD.\nNOTE: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the VNF internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall\n belong to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n","type":"object","required":["cpdId","netAttDefResourceId"],"properties":{"cpdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifiers of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the VNF internal CP created from the CPD identified by cpdId to a secondary container cluster network. See note.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfLinkPort":{"description":"Externally provided link ports to be used to connect VNFC connection points to this externally-managed VL on this network resource. If this attribute is not present, the VNFM shall create the link ports on the externally-managed VL. See notes 2 and 5.\n","type":"array","items":{"description":"This type represents an externally provided link port to be used to connect a VNFC connection point to an externally managed VL.\n","type":"object","required":["vnfLinkPortId","resourceHandle"],"properties":{"vnfLinkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"extManagedMultisiteVirtualLinkId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"vimConnectionInfo":{"description":"Information about VIM or CISM connections to be used for managing the resources for the VNF instance, or refer to external/externally-managed virtual links. This attribute shall only be supported and may be present if - the resources for at least one of the VNFCs shall be managed by a VIM and VNF-related resource management in direct mode is applicable. - the resources for at least one of the VNFCs shall be managed by a CISM. The VNFM shall apply the content of this attribute to the \"vimConnectionInfo\" attribute of \"VnfInstance\" according to the rules of JSON Merge Patch (see IETF RFC 7396 [5]).\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"selectedDeployableModule":{"description":"Identifier of a selected deployable module. Only VNFCs based on VDUs that belong to deployable modules listed in this attribute are requested to be instantiated or preserved if they were already instantiated.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceCapacityDefinition":{"description":"Indicates values for resource capacity related attributes pertaining to a descriptor. Values can only be provided for resource capacity related attributes that have been defined in the VNFD as being configurable. Furthermore, provided values shall be within the allowed values indicated in the VNFD.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes.\nThe tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request.\nAt most one tag can be included when the data type is used in a VNF LCM operation request.\nWhen the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.\n","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced.\n","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute 'type' indicates OSCONTAINER and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource. See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resource property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for this virtual compute descriptor. The value is a numberthat indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) that indicates the valid vaues for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"certificateConfigurationData":{"description":"This type provides input information related to certificate management.\nETSI GS NFV-SOL 009 [i.18] specifies the means to discover the applicable certificate management mode of VNFM and configure into the NFVO applicable certificate management mode via the \"NFV-MANO Configuration and Information Management\" interface\n","type":"object","properties":{"overridingCertificateProfiles":{"description":"Overriding certificate profile. This overrides the certificateBaseProfile provided in the VNFD, and the CA and CMF can additionally override aspects of this certificateBaseProfile at later point in the VNF lifecycle if necessary to meet operator security policy.\n","type":"array","items":{"description":"NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\nThis type provides input information to override certificate base profile for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"description":"Issuer of certificates. See note.","type":"string"},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to the subject of the certificate.\nNOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of the certification target subject FQDN. Can be set empty when this certificate is used for encrypted communication using IP address. See note.\n","type":"string"},"organization":{"description":"Information of the certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of the certification target subject Country. See note.","type":"string"},"state":{"description":"Information of the certification target subject State. See note.","type":"string"},"locality":{"description":"Information of the certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of the certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"description":"Basic constraints of certificates. See note.","type":"string"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [14], clause 7.1.19.4). See note.\n","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}}},"securityPolicy":{"description":"Security policy to be satisfied for the certificate.\n","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"number"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"number"}}}},"cmfData":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["endPoint","supportedProtocols"],"properties":{"endPoint":{"description":"End point of CMF instance.","type":"object","properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocols":{"description":"Supported protocols by CMF instance.","type":"array","items":{"description":"Supported protocol by CMF instance.","type":"string","enum":["CMP","CMPv2","EST","SCEP"]}}}}}}}}}},"required":true},"TerminateVnfRequest":{"description":"Parameters for the VNF termination.","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Terminate VNF\" operation.\nNOTE:\tIf the VNF is still in service, requesting forceful termination can \n adversely impact network service.\n","type":"object","required":["terminationType"],"properties":{"terminationType":{"description":"Indicates whether forceful or graceful termination is requested. See note.\nPermitted values: - FORCEFUL: The VNFM will shut down the VNF and release the resources immediately after accepting the request.\n- GRACEFUL: The VNFM will first arrange to take the VNF out of service after accepting the request. Once the operation \n of taking the VNF out of service finishes (irrespective \n of whether it has succeeded or failed) or once the timer \n value specified in the \"gracefulTerminationTimeout\" \n attribute expires, the VNFM will shut down the VNF and \n release the resources.\n","type":"string","enum":["FORCEFUL","GRACEFUL"]},"gracefulTerminationTimeout":{"description":"This attribute is only applicable in case of graceful termination. It defines the time to wait for the VNF to be taken out of service before shutting down the VNF and releasing the resources. The unit is seconds. If not given and the \"terminationType\" attribute is set to \"GRACEFUL\", it is expected that the VNFM waits for the successful taking out of service of the VNF, no matter how long it takes, before shutting down the VNF and releasing the resources.\n","type":"integer"},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"required":true},"HealVnfRequest":{"description":"Parameters for the Heal VNF operation.","content":{"application/json":{"schema":{"type":"object","properties":{"cause":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"healingResource":{"description":"Indicates the kinds of the virtual resource to be healed.\nPermitted values: * VL\n * LINKPORT\n * STORAGE\n * VIRTUALCP\n * COMPUTE\n * OSCONTAINER\n\nDefault value is COMPUTE when the VDUs of the VNF are realized by a set of virtual machines and OSCONTAINER when the VDUs of the VNF are realized by a set of OS containers.\n","type":"array","enum":["VL","LINKPORT","STORAGE","VIRTUALCP","COMPUTE","OSCONTAINER"]}}}}},"required":true},"OperateVnfRequest":{"description":"Parameters for the Operate VNF operation.","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Operate VNF\" operation.\nNOTE:\tThe \"stopType\" and \"gracefulStopTimeout\" attributes shall be absent, \n when the \"changeStateTo\" attribute is equal to \"STARTED\". \n The \"gracefulStopTimeout\" attribute shall be present, when the \"changeStateTo\" \n is equal to \"STOPPED\" and the \"stopType\" attribute is equal to \"GRACEFUL\". \n The \"gracefulStopTimeout\" attribute shall be absent, when the \"changeStateTo\" \n attribute is equal to \"STOPPED\" and the \"stopType\" attribute is equal to \"FORCEFUL\". \n The request shall be treated as if the \"stopType\" attribute has been set to \"FORCEFUL\", \n when the \"changeStateTo\" attribute is equal to \"STOPPED\" and the \"stopType\" attribute \n is absent.\n","required":["changeStateTo"],"properties":{"changeStateTo":{"description":"STARTED: The VNF instance is up and running. STOPPED: The VNF instance has been shut down.\n","type":"string","enum":["STARTED","STOPPED"]},"stopType":{"description":"* FORCEFUL: The VNFM will stop the VNF instance immediately after accepting the request.\n* GRACEFUL: The VNFM instance will first arrange to take the VNF out of service after accepting the request. Once that operation is successful \n or once the timer value specified in the \"gracefulStopTimeout\" attribute\n expires, the VNFM will stop the VNF instance.\n","type":"string","enum":["FORCEFUL","GRACEFUL"]},"gracefulStopTimeout":{"description":"The time interval (in seconds) to wait for the VNF to be taken out of service during graceful stop, before stopping the VNF. See note.\n","type":"integer"},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"required":true},"ChangeExtVnfConnectivityRequest":{"description":"Parameters for the Change external VNF connectivity operation.\n","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Change external VNF connectivity\" operation to modify the external connectivity of a VNF instance. The following behaviour applies for the changes that can be performed with this operation: To change the connection of external CP instances based on certain external CPDs from a \"source\" external \n VL to a different \"target\" external VL, the identifier of the \"target\" external VL shall be sent in the \n \"extVirtualLinkId\" attribute of the \"extVirtualLinks\" parameter, and the \"extCps\" attributes of that parameter \n shall refer via the \"cpdId\" attribute to the external CPDs of the corresponding external connection point \n instances that are to be reconnected to the target external VL.\n\n* NOTE 1: For CP instances that are not part of a trunk this means that all CP instances based on a given external CPD will be reconnected. See clause B.3.3 for an illustration. Likewise, for CP instances that are part of a \n trunk and have the same segmentationId, all CP instances (subports) based on a given external CPD will \n be connected, disconnected or reconnected.\n \n To change the connectivity parameters of the external CPs connected to a particular external VL, including \n changing addresses, the identifier of that external VL shall be sent in the \"extVirtualLinkId\" attribute of the \n \"extVirtualLinks\" parameter, and the \"extCps\" attribute of that parameter shall contain at least those entries \n with modified parameters.\n\n To create a new external CP instance, this shall be based on a certain external CPD that is referenced by at \n least a VDU from which the VNF instance has at least one VNFC instantiated. The newly external CP instance \n connects to the same external VL as other CP instances created based on the same CPD. For creating a new \n external CP instance:\n The \"extVirtualLinkId\" attribute of the \"extVirtualLinks\" parameter indicates the identifier of the \n external VL instance to which the new external CP instance is requested to be connected (refer to \n above behavior).\n \n The \"extCps\" attribute shall refer via the \"cpdId\" attribute to the external CPDs from which a new \n instance is to be created.\n\n* NOTE 2: For the capability to connect to different external VLs, refer to the use of subports. To delete an existing external CP instance:\n The \"extVirtualLinkId\" attribute of the \"extVirtualLinks\" parameter indicates the identifier of the \n external VL instance from which the existing external CP instance is requested to be disconnected.\n \n The \"extCpsDeletion\" attribute shall refer via the \"cpdId\" attribute to the external CPD from which a \n corresponding CP instance will be deleted.\n\n The \" parentCpConfigId\" of the contained \"cpConfig\" in the \"extCps\" shall refer to the particular \n external CP instance to be deleted.\n\n* NOTE 3: If external CPs are requested to be created and connected, and disconnected and deleted in a same operation request, the consumer can provide respective \"extVirtualLinks\", e.g., one for the external CPs \n to be created and connected, and one for the external CPs to disconnect and delete.\n","type":"object","required":["extVirtualLinks"],"properties":{"extVirtualLinks":{"description":"Information about external VLs to change (e.g. connect the VNF to) including configuration information for the CPs via which the VNF instance can attach to this VL. Entries in the list of external VLs that are unchanged need not be supplied as part of this request. The following applies to the \"ExtVirtualLinkData\" information provided in this request, together with the related \"ExtVirtualLinkInfo\" informationknown to the VNFM represented in the \"VnfInstance\" structure (see clause 5.5.2.2) and the related overriding information provided in the \"Grant\" structure (see clause 9.5.2.3): Even if the VNF is not in fully scaled-out state, the API consumer shall provide enough CP configuration records to allow connecting the VNF instance, fully scaled out in all scaling aspects, to the external VLs.\n","type":"array","items":{"description":"This type represents an external VL.\n* NOTE 1:\tA link port is not needed for an external CP instance that exposes a CP in the following cases:\n 1) For a VIP CP directly exposed as an external CP:\n 1.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD.\n 1.2) A dedicated IP address is allocated as VIP address, but the NFVO indicates that no port is needed\n (createExtLinkPort in VnfExtCpConfig set to false).\n 2) For a VIP CP exposed as an external CP via a floating IP address:\n 2.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD, and the VNFC CP\n associated to the VIP CP is also exposed via a floating IP address.\n 3) For a VIRTUAL CP exposed as an external CP.\n 4) For a VNFC CP exposed as an external CP in a secondary container cluster external network or a\n secondary container cluster internal network.\n\n* NOTE 2: An example of the network attachment definition resource when the container infrastructure service\n management is a Kubernetes® instance is a network attachment definition (NAD).\n* NOTE 3: Either \"extCps\" or “extCpsDeletion\" shall be present, but not both.\n","type":"object","required":["id","resourceId"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"extCps":{"description":"External CPs of the VNF to be connected to this external VL. Entries in the list of external CP data that are unchanged need not be supplied if the ExtVirtualLinkData structure is part of a request or response that modifies the external connectivity. See note 3.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}},"extLinkPorts":{"description":"Externally provided link ports to be used to connect external connection points to this external VL. If this attribute is not present, the VNFM shall create the link ports on the external VL except in the cases defined below. See note 1.\n","type":"array","items":{"description":"This type represents an externally provided link port to be used to connect an external connection point to an external VL. * NOTE:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"extNetAttDefResourceData":{"description":"Externally provided network attachment definition resource(s) that provide the specification of the interface to attach external CPs to this external VL. See note 2. It is only applicable if the external VL is realized by a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"This type represents a network attachment definition resource that provides the specification of the interface to be used to connect one or multiple connection points to a secondary container cluster network realizing a VL.\n","type":"object","required":["netAttDefResourceId","resourceHandle"],"properties":{"netAttDefResourceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"extCpsDeletion":{"description":"External CPs of the VNF to be disconnected from this external VL and to be deleted. See note 3.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}}}}},"vimConnectionInfo":{"description":"Information about VIM or CISM connections to be used for managing the resources for the VNF instance, or refer to external virtual links. This attribute shall only be supported and may be present if - the resources for at least one of the VNFCs\n shall be managed by a VIM and VNF-related\n resource management in direct mode is\n applicable.\n - the resources for at least one of the VNFCs\n shall be managed by a CISM.\nThe VNFM shall apply the content of this attribute to the \"vimConnectionInfo\" attribute of \"VnfInstance\" according to the rules of JSON Merge Patch (see IETF RFC 7396 [5]).\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateConfigurationData":{"description":"This type provides input information related to certificate management.\nETSI GS NFV-SOL 009 [i.18] specifies the means to discover the applicable certificate management mode of VNFM and configure into the NFVO applicable certificate management mode via the \"NFV-MANO Configuration and Information Management\" interface\n","type":"object","properties":{"overridingCertificateProfiles":{"description":"Overriding certificate profile. This overrides the certificateBaseProfile provided in the VNFD, and the CA and CMF can additionally override aspects of this certificateBaseProfile at later point in the VNF lifecycle if necessary to meet operator security policy.\n","type":"array","items":{"description":"NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\nThis type provides input information to override certificate base profile for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"description":"Issuer of certificates. See note.","type":"string"},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to the subject of the certificate.\nNOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of the certification target subject FQDN. Can be set empty when this certificate is used for encrypted communication using IP address. See note.\n","type":"string"},"organization":{"description":"Information of the certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of the certification target subject Country. See note.","type":"string"},"state":{"description":"Information of the certification target subject State. See note.","type":"string"},"locality":{"description":"Information of the certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of the certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"description":"Basic constraints of certificates. See note.","type":"string"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [14], clause 7.1.19.4). See note.\n","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}}},"securityPolicy":{"description":"Security policy to be satisfied for the certificate.\n","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"number"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"number"}}}},"cmfData":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["endPoint","supportedProtocols"],"properties":{"endPoint":{"description":"End point of CMF instance.","type":"object","properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocols":{"description":"Supported protocols by CMF instance.","type":"array","items":{"description":"Supported protocol by CMF instance.","type":"string","enum":["CMP","CMPv2","EST","SCEP"]}}}}}}}}}},"required":true},"ChangeCurrentVnfPkgRequest":{"description":"Parameters for the Change current VNF package operation, as defined in clause 5.5.2.11a.\n","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Change current VNF package\" operation to replace the VNF package on which a VNF instance is based.\nNOTE 1:\tThe indication of externally-managed internal VLs is needed in case networks \n have been pre-configured for use with certain VNFs, for instance to ensure \n that these networks have certain properties such as security or acceleration \n features, or to address particular network topologies. The present document \n assumes that externally-managed internal VLs are managed by the NFVO and created \n towards the VIM.\nNOTE 2:\tIt is possible to have several ExtManagedVirtualLinkData for the same VNF internal \n VL in case of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkData \n corresponding to the same VNF internal VL shall indicate so by referencing to the same \n VnfVirtualLinkDesc and externally-managed multi-site VL instance (refer to clause 4.4.1.12).\nNOTE 3: Component mappings are defined in the VNFD in the source or destination package for the relevant change \n path. See clause 7.1.15.2 in ETSI GS NFV-IFA 011 [13].\nNOTE 4: In the current version of the present document, only Rolling upgrade and Blue-green \n upgrade types are supported. The definition of additional upgrade types is left for future \n specification.\n","type":"object","required":["vnfdId"],"properties":{"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"extVirtualLinks":{"description":"Information about external VLs to connect the VNF to, including configuration information for the CPs via which the VNF instance can attach to this VL. Entries in the list that are unchanged need not be supplied as part of this request. The following applies to the \"ExtVirtualLinkData\" information provided in this request, together with the related \"ExtVirtualLinkInfo\" information known to the VNFM represented in the \"VnfInstance\" structure (see clause 5.5.2.2) and the related overriding information provided in the \"Grant\" structure (see clause 9.5.2.3): Even if the VNF is not in fully scaled-out state after the change of the VNF package, the API consumer shall provide enough CP configuration records to allow connecting the VNF instance, fully scaled out in all scaling aspects, to the external VLs.\n","type":"array","items":{"description":"This type represents an external VL.\n* NOTE 1:\tA link port is not needed for an external CP instance that exposes a CP in the following cases:\n 1) For a VIP CP directly exposed as an external CP:\n 1.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD.\n 1.2) A dedicated IP address is allocated as VIP address, but the NFVO indicates that no port is needed\n (createExtLinkPort in VnfExtCpConfig set to false).\n 2) For a VIP CP exposed as an external CP via a floating IP address:\n 2.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD, and the VNFC CP\n associated to the VIP CP is also exposed via a floating IP address.\n 3) For a VIRTUAL CP exposed as an external CP.\n 4) For a VNFC CP exposed as an external CP in a secondary container cluster external network or a\n secondary container cluster internal network.\n\n* NOTE 2: An example of the network attachment definition resource when the container infrastructure service\n management is a Kubernetes® instance is a network attachment definition (NAD).\n* NOTE 3: Either \"extCps\" or “extCpsDeletion\" shall be present, but not both.\n","type":"object","required":["id","resourceId"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"extCps":{"description":"External CPs of the VNF to be connected to this external VL. Entries in the list of external CP data that are unchanged need not be supplied if the ExtVirtualLinkData structure is part of a request or response that modifies the external connectivity. See note 3.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}},"extLinkPorts":{"description":"Externally provided link ports to be used to connect external connection points to this external VL. If this attribute is not present, the VNFM shall create the link ports on the external VL except in the cases defined below. See note 1.\n","type":"array","items":{"description":"This type represents an externally provided link port to be used to connect an external connection point to an external VL. * NOTE:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"extNetAttDefResourceData":{"description":"Externally provided network attachment definition resource(s) that provide the specification of the interface to attach external CPs to this external VL. See note 2. It is only applicable if the external VL is realized by a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"This type represents a network attachment definition resource that provides the specification of the interface to be used to connect one or multiple connection points to a secondary container cluster network realizing a VL.\n","type":"object","required":["netAttDefResourceId","resourceHandle"],"properties":{"netAttDefResourceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"extCpsDeletion":{"description":"External CPs of the VNF to be disconnected from this external VL and to be deleted. See note 3.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}}}}},"extManagedVirtualLinks":{"description":"Information about internal VLs that are managed by the NFVO. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents an externally-managed internal VL.\n* NOTE 1: It is only applicable if the externally-managed VL is realized by a secondary container cluster network. It shall not be present otherwise.\n* NOTE 2: A link port is not needed for a VNFC internal connection point connected to a secondary container cluster network.\n* NOTE 3: An example of the network attachment definition resource when the container infrastructure service management is a Kubernetes® instance is a network attachment definition (NAD).\n\n* NOTE 4: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, an instance of intCp need not be included for each VNFC instance as all instances would contain the same \n information. It is sufficient to include one intCp for the related CPD. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version\n* NOTE 5: Both \"vnfLinkPort\" and \"netAttDefResource\" attributes can be provided in a \"ExtManagedVirtualLinkData\" to indicate that a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs\n","type":"object","required":["id","vnfVirtualLinkDescId","resourceId"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"netAttDefResourceData":{"description":"Externally provided network attachment definition resource(s) that provide the specification of the interface to attach VNFC connection points to this externallymanaged VL. See notes 1, 3 and 5.\n","type":"array","items":{"description":"This type represents a network attachment definition resource that provides the specification of the interface to be used to connect one or multiple connection points to a secondary container cluster network realizing a VL.\n","type":"object","required":["netAttDefResourceId","resourceHandle"],"properties":{"netAttDefResourceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"intCp":{"description":"Internal CPs of the VNF to be connected to this externally-managed VL. See note 1 and 4.\n","type":"array","items":{"description":"This type represents input information related to one or more VNF internal CP instances created based on the same CPD.\nNOTE: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the VNF internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall\n belong to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n","type":"object","required":["cpdId","netAttDefResourceId"],"properties":{"cpdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifiers of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the VNF internal CP created from the CPD identified by cpdId to a secondary container cluster network. See note.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfLinkPort":{"description":"Externally provided link ports to be used to connect VNFC connection points to this externally-managed VL on this network resource. If this attribute is not present, the VNFM shall create the link ports on the externally-managed VL. See notes 2 and 5.\n","type":"array","items":{"description":"This type represents an externally provided link port to be used to connect a VNFC connection point to an externally managed VL.\n","type":"object","required":["vnfLinkPortId","resourceHandle"],"properties":{"vnfLinkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"extManagedMultisiteVirtualLinkId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"vimConnectionInfo":{"description":"Information about VIM or CISM connections to be used for managing the resources for the VNF instance, or refer to external virtual links. This attribute shall only be supported and may be present if - the resources for at least one of the VNFCs shall be managed by a VIM and\n VNF-related resource management in direct mode is applicable.\n - the resources for at least one of the VNFCs shall be managed by a CISM.\n The VNFM shall apply the content of this attribute to the \"vimConnectionInfo\" attribute of\n\"VnfInstance\" according to the rules of JSON Merge Patch (see IETF RFC 7396 [5]).\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"selectedDeployableModule":{"description":"Identifier of a selected deployable module.\nIf this attribute is present only VNFCs based on VDUs that belong to deployable modules listed in this attribute are requested to be instantiated or preserved if they were already instantiated.\nIf this attribute is not present the deployable modules that were selected before the operation, and that still are defined in the VNFD in the destination package, or the corresponding ones according to the component mappings, remain valid. See note 3.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceCapacityDefinition":{"description":"Indicates values for resource capacity related attributes pertaining to a descriptor. Values can only be provided for resource capacity related attributes that have been defined in the VNFD as being configurable. Furthermore, provided values shall be within the allowed values indicated in the VNFD.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes.\nThe tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request.\nAt most one tag can be included when the data type is used in a VNF LCM operation request.\nWhen the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.\n","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced.\n","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute 'type' indicates OSCONTAINER and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource. See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resource property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for this virtual compute descriptor. The value is a numberthat indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) that indicates the valid vaues for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"certificateConfigurationData":{"description":"This type provides input information related to certificate management.\nETSI GS NFV-SOL 009 [i.18] specifies the means to discover the applicable certificate management mode of VNFM and configure into the NFVO applicable certificate management mode via the \"NFV-MANO Configuration and Information Management\" interface\n","type":"object","properties":{"overridingCertificateProfiles":{"description":"Overriding certificate profile. This overrides the certificateBaseProfile provided in the VNFD, and the CA and CMF can additionally override aspects of this certificateBaseProfile at later point in the VNF lifecycle if necessary to meet operator security policy.\n","type":"array","items":{"description":"NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\nThis type provides input information to override certificate base profile for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"description":"Issuer of certificates. See note.","type":"string"},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to the subject of the certificate.\nNOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of the certification target subject FQDN. Can be set empty when this certificate is used for encrypted communication using IP address. See note.\n","type":"string"},"organization":{"description":"Information of the certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of the certification target subject Country. See note.","type":"string"},"state":{"description":"Information of the certification target subject State. See note.","type":"string"},"locality":{"description":"Information of the certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of the certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"description":"Basic constraints of certificates. See note.","type":"string"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [14], clause 7.1.19.4). See note.\n","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}}},"securityPolicy":{"description":"Security policy to be satisfied for the certificate.\n","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"number"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"number"}}}},"cmfData":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["endPoint","supportedProtocols"],"properties":{"endPoint":{"description":"End point of CMF instance.","type":"object","properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocols":{"description":"Supported protocols by CMF instance.","type":"array","items":{"description":"Supported protocol by CMF instance.","type":"string","enum":["CMP","CMPv2","EST","SCEP"]}}}}}},"upgradeType":{"description":"Indicates upgrade type when change the current VNF Package on which a VNF instance is based. Permitted values: * ROLLING_UPGRADE\n * BLUE_GREEN\nSee note 4.\n","type":"string","enum":["ROLLING_UPGRADE","BLUE_GREEN"]}}}}},"required":true},"LccnSubscriptionRequest":{"description":"Details of the subscription to be created.\n","content":{"application/json":{"schema":{"description":"This type represents a subscription request related to notifications about VNF lifecycle changes.\n","type":"object","required":["callbackUri"],"properties":{"filter":{"description":"This type represents a subscription filter related to notifications about VNF lifecycle changes.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of \n the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdId"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tVnfLcmOperationOccurrenceNotification -\tVnfIdentifierCreationNotification -\tVnfIdentifierDeletionNotification See note.\n","type":"array","items":{"type":"string","enum":["VnfLcmOperationOccurrenceNotification","VnfIdentifierCreationNotification","VnfIdentifierDeletionNotification"]}},"operationTypes":{"description":"Match particular VNF lifecycle operation types for the notification of type VnfLcmOperationOccurrenceNotification. May be present if the \"notificationTypes\" attribute contains the value \"VnfLcmOperationOccurrenceNotification\", and shall be absent otherwise.\n","type":"array","items":{"description":"The enumeration LcmOpType defines the permitted values to represent VNF lifecycle operation types in VNF lifecycle management operation occurrence resources and VNF lifecycle management operation occurrence notifications.\nValue | Description ------|------------ INSTANTIATE | Represents the \"Instantiate VNF\" LCM operation. SCALE | Represents the \"Scale VNF\" LCM operation. SCALE_TO_LEVEL | Represents the \"Scale VNF to Level\" LCM operation. CHANGE_FLAVOUR | Represents the \"Change VNF Flavour\" LCM operation. TERMINATE | Represents the \"Terminate VNF\" LCM operation. HEAL | Represents the \"Heal VNF\" LCM operation. OPERATE | Represents the \"Operate VNF\" LCM operation. CHANGE_EXT_CONN | Represents the \"Change external VNF connectivity\" LCM operation. MODIFY_INFO | Represents the \"Modify VNF Information\" LCM operation. CREATE_SNAPSHOT | Represents the \"Create VNF Snapshot\" LCM operation. REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot\" LCM operation. CHANGE_VNFPKG | Represents the \"Change current VNF package\" LCM operation. SELECT_DEPL_MODS | Represents the “Select VNF deployable modules” LCM operation\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","MODIFY_INFO","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","CHANGE_VNFPKG","SELECT_DEPL_MODS"]}},"operationStates":{"description":"Match particular LCM operation state values as reported in notifications of type VnfLcmOperationOccurrenceNotification. May be present if the \"notificationTypes\" attribute contains the value \"VnfLcmOperationOccurrenceNotification\", and shall be absent otherwise.\n","type":"array","items":{"description":"STARTING: The LCM operation is starting. PROCESSING: The LCM operation is currently in execution. COMPLETED: The LCM operation has been completed successfully. FAILED_TEMP: The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED: The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK: The LCM operation is currently being rolled back. ROLLED_BACK: The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible.\n","type":"string","enum":["STARTING","PROCESSING","COMPLETED","FAILED_TEMP","FAILED","ROLLING_BACK","ROLLED_BACK"]}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE 1 : The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between\n subscriptions. The value of clientPassword should be generated by a random process.\n* NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT which uses mutual authentication based on X.509 certificates, this mode which uses client password to authenticate may be used in the access token request\n toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations\n (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details.\n* NOTE 3: The following values that were included up to version 3.4.1 of the present document have been removed: \"BASIC\" (to signal the use of the basic HTTP authentication) has been removed because it is insecure.\n \"TLS_CERT\" to signal an alternative non-token based authorization method using TLS certificates has been\n removed because the method is no longer supported.\n* NOTE 4: The client certificate is established by means outside the scope of the present document.\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values (see note 3): * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use\n an OAuth 2.0 token, obtained using the client\n credentials grant type after authenticating\n using client identifier and client password\n towards the token endpoint.\n* OAUTH2_CLIENT_CERT: In every HTTP request to the notification endpoint, use an\n OAuth 2.0 token, obtained using the client\n credentials grant type after mutually\n authenticating using client identifier and X.509\n certificates towards the token endpoint.\n","type":"array","items":{"type":"string","enum":["OAUTH2_CLIENT_CREDENTIALS","OAUTH2_CLIENT_CERT"]}},"paramsOauth2ClientCert":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CERT.\nShall be present if authType is \"OAUTH2_CLIENT_CERT\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\n","type":"object","required":["clientId","certificateRef","tokenEndpoint"],"properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint.\n","type":"string"},"certificateRef":{"description":"Fingerprint of the client certificate. The hash function shall use SHA256 or higher. See note 4.\n","type":"string","required":["type","value"],"properties":{"type":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"value":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS.\nShall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\nSee note 2.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"clientPassword":{"description":"Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"verbosity":{"description":"The enumeration LcmOpOccNotificationVerbosityType provides values to control the verbosity of LCM operation occurrence notifications. * FULL: This signals a full notification which contains all change details. * SHORT: This signals a short notification which omits large-volume change details to reduce the size of data to be sent via the notification mechanism.\n","type":"string","enum":["FULL","SHORT"]}}}}},"required":true},"CreateVnfSnapshotRequest":{"description":"Parameters for the \"Create VNF Snapshot\" operation, as defined in clause 5.5.2.21.\n","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Create VNF Snapshot\" LCM operation which takes a snapshot of a VNF instance and populates a previously-created \"Individual VNF snapshot\" resource with the content of the snapshot.\n","type":"object","required":["vnfSnapshotResId"],"properties":{"vnfSnapshotInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"required":true},"RevertToVnfSnapshotRequest":{"description":"Parameters for the Revert to VNF snapshot operation, as defined in clause 5.5.2.26.\n","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Revert to VNF Snapshot\" operation.\n","type":"object","required":["vnfSnapshotInfoId"],"properties":{"vnfSnapshotInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"required":true},"SelectVnfDeployableModulesRequest":{"description":"This type represents request parameters for the \"Select VNF deployable modules\" operation.\n","content":{"application/json":{"schema":{"description":"This type represents request parameters for the \"Select VNF deployable modules\" operation.\n* NOTE 1: Thus, the select VNF deployable modules operation cannot be used as a scale VNF operation to scale VNFCs that were already instantiated.\n* NOTE 2: Thus, the select VNF deployable modules operation cannot be used as a scale VNF operation to vertically scale VNFCs that were already instantiated.\n","type":"object","properties":{"selectedDeployableModule":{"description":"Identifier of a selected deployable module, as defined in the VNFD. VNFCs based on VDUs that belong to deployable modules listed in this attribute will be instantiated if not already instantiated. VNFCs based on VDUs that belong to deployable modules not listed in this attribute and that were already instantiated will be terminated.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"targetScaleLevelInfo":{"description":"Defines the target scale levels of scaling aspects of the VDUs that belong to selected deployable modules. If this attribute is not present or if there are VDUs that belong to selected deployable modules that take no part in any of the scaling aspects indicated in this attribute, the VNFCs based on those VDUs shall be instantiated according to the currently valid VNF scale level or instantiation level. This attribute should only contain scale level information of scaling aspects associated with VDUs that will be used to instantiate VNFCs as a result of this operation. If it contains other scale level information, it shall be ignored. See note.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"resourceCapacityDefinition":{"description":"Indicates values for resource capacity related attributes pertaining to a descriptor. Values can only be provided for resource capacity related attributes that have been defined in the VNFD as being configurable. Furthermore, provided values shall be within the allowed values indicated in the VNFD.\nThis attribute should only contain information about resource capacity related attributes of VDUs that will be used to instantiate VNFCs as a result of this operation. If it contains information about attributes of other VDUs it shall be ignored. See note 2.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes.\nThe tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request.\nAt most one tag can be included when the data type is used in a VNF LCM operation request.\nWhen the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.\n","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced.\n","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute 'type' indicates OSCONTAINER and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource. See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resource property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for this virtual compute descriptor. The value is a numberthat indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) that indicates the valid vaues for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"required":true},"CreateVnfSnapshotInfoRequest":{"description":"The VNF snapshot resource creation parameters, as defined in clause 5.5.2.20.\n","content":{"application/json":{"schema":{"description":"This type represents request parameters for the creation of an \"Individual VNF snapshot\" \nresource which can be populated with content obtained by invoking the \"Create VNF snapshot\" \nLCM operation or extracted from a VNF snapshot package.\n\nNOTE:\tThe present attribute shall be provided if the \"Individual VNF snapshot\" resource is \n requested to be created as part of a VNF snapshot package extraction.\n","type":"object","properties":{"vnfSnapshotPkgId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfSnapshot":{"description":"This type represents a VNF snapshot.\n","type":"object","required":["id","vnfInstanceId","triggeredAt","vnfdId","vnfInfo","vnfcSnapshots"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"creationStartedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"creationFinishedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstance":{"description":"This type represents a VNF instance.\nNOTE:\tClause B.3.2 provides examples illustrating the relationship among the different run-time \n information elements (CP, VL and link ports) used to represent the connectivity of a VNF.\n\nNOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist between \n the previous and the newly referred VNF package, i.e. when the new VNFD is changed with \n respect to the previous VNFD in other aspects than merely referencing to other VNF software \n images. In order to avoid misalignment of the VnfInstance with the current VNF's on-boarded \n VNF Package, the values of attributes in the VnfInstance that have corresponding attributes \n in the VNFD shall be kept in sync with the values in the VNFD.\nNOTE 2:\tETSI GS NFV-SOL 001 [14] specifies the structure and format of the VNFD based on TOSCA specifications. NOTE 3:\tVNF configurable properties are sometimes also referred to as configuration parameters applicable \n to a VNF. Some of these are set prior to instantiation and cannot be modified if the VNF is instantiated, \n some are set prior to instantiation (are part of initial configuration) and can be modified later, \n and others can be set only after instantiation. The applicability of certain configuration may \n depend on the VNF and the required operation of the VNF at a certain point in time.\nNOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes \n of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared in the VNFD with a defined \n initial value. The defined initial values can be declared in the VNFD, and/or, in case of \"metadata\", \n obtained from the \"CreateVnfRequest\" structure. Child attributes of \"vnfConfigurableProperties\", \n \"metadata\" and \"extensions\" that have no defined initial value shall not be created, in order to be \n consistent with the semantics of the JSON Merge Patch method (see IETF RFC 7396) that interprets null \n values as deletion request.\nNOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a \n multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same \n VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed \n multi-site VL instance (refer to clause 5.5.3.3).\nNOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity, they shall \n not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\nNOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing \n the trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\nNOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the \n VNF LCM operation explicitly indicates the scale level for the aspect.\nNOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n","type":"object","required":["id","vnfdId","vnfProvider","vnfProductName","vnfSoftwareVersion","vnfdVersion","instantiationState","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceName":{"description":"Name of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfInstanceDescription":{"description":"Human-readable description of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"Provider of the VNF and the VNFD. The value is copied from the VNFD.\n","type":"string"},"vnfProductName":{"description":"Name to identify the VNF Product. The value is copied from the VNFD.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vimConnectionInfo":{"description":"Information about VIM or CISM connections to be used for managing the resources for the VNF instance. The keys of the map, each of which identifies information about a particular VIM connection, are managed by the NFVO and referenced from other data structures via the \"vimConnectionId\" attribute. This attribute shall only be supported and present if - the resources of at least of the VNFCs are managed by a VIM and VNF-related resource management in direct mode is applicable. - the resources of at least of the VNFCs are managed by a CISM. This attribute can be modified with the PATCH method. If VIM connection information is provisioned to the VNFM by means outside the scope of the present document, the information in the \"vimConnectionInfo\" attribute provides necessary information for binding the VnfInstance representing the \"Individual VNF instance\" to the applicable VIM connection information used to perform resource management for the VNF instance. See also the definition of the \"VimConnectionInfo\" in clause 4.4.1.6.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"cirConnectionInfo":{"description":"Information about the CIR connection for managing OS container images for the VNF instance. Shall be present when all or part of the VNF is realized by a set of OS containers and shall be absent otherwise.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mciopRepositoryInfo":{"description":"Information about the MCIOP repository for the VNF instance. Shall be present when all or part of the VNF is realized by a set of OS containers and shall be absent otherwise. See note 1.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"certificateInfo":{"description":"This type provides input information related to certificate and certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateConfigurationInfo":{"description":"This type provides input information related to certificate management.\n","type":"object","required":["securityPolicy"],"properties":{"certificateBaseProfile":{"description":"Information for certificate profile.","type":"array","items":{"description":"NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\nThis type provides input information to override certificate base profile for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"description":"Issuer of certificates. See note.","type":"string"},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to the subject of the certificate.\nNOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of the certification target subject FQDN. Can be set empty when this certificate is used for encrypted communication using IP address. See note.\n","type":"string"},"organization":{"description":"Information of the certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of the certification target subject Country. See note.","type":"string"},"state":{"description":"Information of the certification target subject State. See note.","type":"string"},"locality":{"description":"Information of the certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of the certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"description":"Basic constraints of certificates. See note.","type":"string"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [14], clause 7.1.19.4). See note.\n","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}}},"securityPolicy":{"description":"Information for security policy to be satisfied for certificate.","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"number"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"number"}}}},"delegationSupportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"cmfInfo":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["id","endPoint","supportedProtocol"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"endPoint":{"description":"End point of CMF instance.","type":"object","properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocol":{"description":"Supported protocols by CMF instance.","type":"array","items":{"description":"Supported protocol by CMF instance.","type":"string","enum":["CMP","CMPv2","EST","SCEP"]}},"certificateChain":{"description":"Certificate chain that this CMF provides.","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"certificateContents":{"description":"Information for contents of issued certificates. The information contained in this attribute may be updated over time during the VNF LCM, e.g., certificate(s) renewal.\n","type":"array","items":{"description":"This type provides input information related to certificate content.\nNOTE: The CertificateDesc data type is defined in clause 7.1.19.2 of ETSI GS NFV IFA 011 [10].\n","type":"object","required":["id","certificateDescId","certificateType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"certificateType":{"description":"Type of this certificate.","type":"string","enum":["VNFCI_CERT","VNFOAM_CERT"]},"supportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"version":{"description":"A version.\n","type":"string"},"serialNumber":{"description":"Serial number of this certificate.","type":"integer"},"signatureAlgorithm":{"description":"Algorithm of this certificate's signature.","type":"string"},"issuer":{"description":"Issuer of this certificate.","type":"string"},"notBefore":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"notAfter":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"subject":{"description":"Subject of this certificate.","type":"string"},"publicKeyAlgorithm":{"description":"Algorithm of this certificate's public key.","type":"string"},"publicKey":{"description":"Public key of this certificate.","type":"string"},"certificateExtensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"instantiationState":{"description":"The instantiation state of the VNF. Permitted values: - NOT_INSTANTIATED: The VNF instance is terminated or not instantiated. - INSTANTIATED: The VNF instance is instantiated.\n","type":"string","enum":["NOT_INSTANTIATED","INSTANTIATED"]},"instantiatedVnfInfo":{"description":"Information specific to an instantiated VNF instance. This attribute shall be present if the instantiateState attribute value is INSTANTIATED.\n","type":"object","required":["flavourId","vnfState"],"properties":{"flavourId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfState":{"description":"STARTED: The VNF instance is up and running. STOPPED: The VNF instance has been shut down.\n","type":"string","enum":["STARTED","STOPPED"]},"vnfPowerState":{"description":"This type represents information about the power state of a VNF instance.\n","type":"object","required":["powerProfileId","name"],"properties":{"powerProfileId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Name of the power profile as provided in the VNFD.\n","type":"string"},"powerConsumptionInfo":{"description":"This type represents information about estimated power consumption of the resources associated with the power profile, as provided in the VNFD.\n","type":"object","required":["minPowerConsumption","maxPowerConsumption","averagePowerConsumption"],"properties":{"minPowerConsumption":{"description":"Minimum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"maxPowerConsumption":{"description":"Maximum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"averagePowerConsumption":{"description":"Average power consumption of this power profile. Unit is KW/h.\n","type":"integer"}}}}},"scaleStatus":{"description":"Scale status of the VNF, one entry per aspect. Represents for every scaling aspect how \"big\" the VNF has been scaled w.r.t. that aspect.\nThis attribute shall be present if the VNF supports scaling. See clause B.2 for an explanation of VNF scaling.\nFor an aspect that has not been deployed because the related deployableModule has not been selected, it indicates the scale level that has been requested in the instantiation or in a scaling operation, or, if none has been requested in any of them, the scale level applicable to the aspect based on the default instantiation level. See note 8.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"maxScaleLevels":{"description":"Maximum allowed scale levels of the VNF, one entry per aspect. This attribute shall be present if the VNF supports scaling.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"selectedDeployableModule":{"description":"References a currently selected deployable module, as defined in the VNFD, that has already completed the instantiation of its VNFCs.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceCapacityDefinition":{"description":"Shows current values of VDU attributes related to resource capacity, if different to the default values from the VNFD, as indicated in the (one or more) request(s) of all completed VNF LCM operation(s) that contain this attribute. If an attribute value has been modified multiple times, only the last value is shown. The values indicated in this attribute are applicable to all VNFC instances based on the VDU to which the resourceCapacityDefinition is related.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes.\nThe tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request.\nAt most one tag can be included when the data type is used in a VNF LCM operation request.\nWhen the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.\n","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced.\n","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute 'type' indicates OSCONTAINER and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource. See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resource property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for this virtual compute descriptor. The value is a numberthat indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) that indicates the valid vaues for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"extCpInfo":{"description":"Information about the external CPs exposed by the VNF instance. When trunking is enabled, the list of entries includes both, external CPs corresponding to parent ports of a trunk, and external CPs associated to sub-ports of a trunk.See note 7.\n","type":"array","items":{"description":"This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n","type":"object","required":["id","cpdId","cpConfigId","cpProtocolInfo"],"oneOf":[{"required":["associatedVnfcCpId"]},{"required":["associatedVipCpId"]},{"required":["associatedVnfVirtualLinkId"]}],"properties":{"id":{"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"},"cpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extLinkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"associatedVnfcCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVipCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVirtualCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVnfVirtualLinkId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 3 and 4.\nIt shall be present if the external CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNF CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpSecurityGroupInfo":{"description":"This type provides the list of active security group rules applied to an external CP instance. The type identifies which \"SecurityGroupRule\" specified in the VNFD are activated and the values of its attributes.\n","type":"object","required":["securityGroupRuleId","etherType","protocol","portRangeMin","portRangeMax"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"description":{"description":"Human readable description of the security group rule.\n","type":"string"},"etherType":{"description":"Indicates the protocol carried over the Ethernet layer. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"protocol":{"description":"Indicates the protocol carried over the IP layer. Permitted values: any protocol defined in the IANA protocol registry (refer to clause 9.10.1.2 ofd ETSI GS NFV-SOL 001 for further information).\n","type":"string"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule.\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule.\n","type":"integer"}}}}}},"vipCpInfo":{"description":"VIP CPs that are part of the VNF instance. Shall be present when that particular VIP CP of the VNFC instance is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","minItems":1,"items":{"description":"This type provides information related to virtual IP (VIP) CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["cpInstanceId","cpdId"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for layer 3. There may be one cpProtocolInfo for layer 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"associatedVnfcCpIds":{"description":"Identifiers of the VnfcCps that share the virtual IP address allocated to the VIP CP instance. See note.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualCpInfo":{"description":"Virtual CPs that are part of the VNF instance. Shall be present when a particular Virtual CP is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","items":{"description":"This type provides information related to a virtual CP instance of a VNF.\nNOTE 1: A consumer of the VNF LCM interface can learn the actual VNFC instances implementing the service accessible via the virtual CP instance by querying the \"vnfcResourceInfo\" from the \"InstantiatedVnfInfo\" \n and filtering by corresponding \"vduIds\" values.\nNOTE 2: The information can be omitted because it is already available as part of the external CP information in the VnfExtCpInfo structure.\n","type":"object","required":["cpInstanceId","cpdId","resourceHandle","vduIds"],"properties":{"cpInstanceId":{"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"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for each layer protocol supported. This attribute may be omitted if the virtual CP is exposed as an external CP. See note 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vduIds":{"description":"Reference to the VDU(s) which implement the service accessible via the virtual CP instance. See note 1.\n","type":"array","minItems":1,"items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"additionalServiceInfo":{"description":"Additional service identification information of the virtual CP instance.\n","type":"array","items":{"description":"This type provides additional service information of the virtual CP instance used to expose properties of the virtual CP to NFV-MANO.\nNOTE: This attribute shall only be present if additional information is needed to identify the service termination within the VNF, such as for example a URL path information in an HTTP request required \n to allow a single virtual CP IP address to be used for several HTTP based services that use the \n same port number.\n","type":"object","required":["portInfo"],"properties":{"portInfo":{"description":"Service port numbers exposed by the virtual CP instance.\n","minItems":1,"type":"array","items":{"description":"This type describes the service identifying port properties exposed by the virtual CP instance.\n","type":"object","required":["name","port","portConfigurable"],"properties":{"name":{"description":"The name of the port exposed by the virtual CP instance.\n","type":"string"},"protocol":{"description":"The L4 protocol for this port exposed by the virtual CP instance.\nPermitted values: - TCP - UDP - SCTP\n","type":"string","enum":["TCP","UDP","SCTP"]},"port":{"description":"The L4 port number exposed by the virtual CP instance.\n","type":"integer"},"portConfigurable":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"}}}},"serviceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"extVirtualLinkInfo":{"description":"Information about the external VLs the VNF instance is connected to.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extManagedVirtualLinkInfo":{"description":"Information about the externally-managed internal VLs of the VNF instance. See notes 5 and 6.\n","type":"array","items":{"description":"This type provides information about an externally-managed virtual link. Note: Both \"vnfLinkPort\" and \"vnfNetAttDefResource\" attributes can be present in an \"ExtManagedVirtualLinkInfo\" to indicate that a single internal virtual link is providing connectivity for both VM-based and container-based \n VNFCs.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPorts":{"description":"Link ports of this VL. See note.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"vnfNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL. See note.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"extManagedMultisiteVirtualLinkId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"routingResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"monitoringParameters":{"description":"Active monitoring parameters.\n","type":"array","items":{"description":"This type represents a monitoring parameter that is tracked by the VNFM,\n","type":"object","required":["id","performanceMetric"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human readable name of the monitoring parameter, as defined in the VNFD.\n","type":"string"},"performanceMetric":{"description":"Performance metric that is monitored. This attribute shall contain the related \"Measurement Name\" value as defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"}}}},"localizationLanguage":{"description":"Information about localization language of the VNF (includes e.g. strings in the VNFD). The localization languages supported by a VNF can be declared in the VNFD, and localization language selection can take place at instantiation time. The value shall comply with the format defined in IETF RFC 5646.\n","type":"string"},"vnfcResourceInfo":{"description":"Information about the virtualised compute and storage resources used by the VNFCs of the VNF instance.\n","type":"array","items":{"description":"This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure of\n information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n a) For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n b) For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\nNOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on \n TOSCA specifications.\nNOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an \n internal VL that exposes an external CP. A VNFC CP is \"exposed as\" an external \n CP if it is connected directly to an external VL.\nNOTE 3:\tThe information can be omitted because it is already available as part of the \n external CP information.\nNOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\"\n structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVnfc\" structure in the VNF LCM operation occurrence notifications\n or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\nNOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment\n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. \nNOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n","type":"object","required":["id","vduId","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResourceIds":{"description":"References to the VirtualStorage resources or references to Storage MCIOs. The value refers to a VirtualStorageResourceInfo item in the VnfInstance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcCpInfo":{"description":"CPs of the VNFC instance. Shall be present when that particular CP of the VNFC instance is exposed as an external CP of the VNF instance or is connected to an external CP of the VNF instance. See note 2. May be present otherwise. See note 7.\n","type":"array","items":{"type":"object","required":["id","cpdId"],"properties":{"id":{"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"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP. May be omitted if the VNFC CP is exposed as an external CP. See note 3.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"parentCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 5 and 6. It shall be present if the internal CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfVirtualLinkResourceInfo":{"description":"Information about the virtualised network resources used by the VLs of the VNF instance. See note 6.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by an internal VL instance in a VNF instance.\nNote: If only the value or the presence of this attribute is changed in the \"VnfVirtualLinkResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including\n a related \"AffectedVirtualLink\" structure in the VNF LCM operation occurrence notifications or the\n \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLinkPorts":{"description":"Links ports of this VL. Shall be present when the linkPort is used for external connectivity by the VNF (refer to VnfLinkPortInfo). May be present otherwise.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualStorageResourceInfo":{"description":"Information on the virtualised storage resource(s) used as storage for the VNF instance.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance.\nNote: If only the value or the presence of this attribute is changed in the \"VirtualStorageResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVirtualStorage\" structure in the VNF LCM operation occurrence\n notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","virtualStorageDescId","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mcioInfo":{"description":"Information on the MCIO(s) representing VNFC instance(s) realized by one or a set of OS containers and created from the same VDU for the VNF instance.\n","type":"array","items":{"description":"This type provides information about an MCIO representing the set of VNFC instances realized by one or a set of OS containers which have been created based on the same VDU. Within the CISM, an MCIO controller monitors the actual state of an MCIO representing the set of VNFC instances realized by one or a set of OS containers and compare it to the desired state For an MCIO related to a VDU that has the attribute isNumOfInstancesClusterBased set to FALSE the desired state is specified in the respective declarative descriptor. For an MCIO related to a VDU that has the attribute isNumOfInstancesClusterBased set to TRUE, the desired state is determined by the number of CIS-nodes in the cluster that fulfil the VDU requirements.as specified in the respective declarative descriptor. It triggers actions toward the CIS to align the actual to the desired state. Monitoring the actual state includes monitoring the number of MCIO instances available at any specific point in time. In addition, an MCIO controller maintains properties and runtime information on the MCIO instances which have been created based on the same VDU. The McioInfo data structure provides the runtime information on the MCIOs obtained from the MCIO controller.\nNOTE: There are different types of MCIOs. The set of VNFC instances based on the same VDU is represented by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type \n of MCIO, e.g. a POD.\n\nRuntime information of the set of OS containers realizing an individual VNFC instance is not part of the McioInfo data structure; such runtime information is provided in the ResourceHandle data structure referenced from the VnfcResourceInfo. The McioInfo does not provide runtime information of a constituent VNFC instance created based on a specific VDU.\nNOTE 1: The type of MCIO as specified in the declarative descriptor of the MCIO, and that can be read from the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the \n “kind” property of the declarative descriptor.\nNOTE 2: If the attribute additionalInfo is present, it may contain runtime information on the actual and desired state of the MCIO(s). \nNOTE 3: When the container infrastructure service is a Kubernetes® instance, the mcioId is the combined values from the kind and name fields of the Kubernetes resource object, separated by a slash. \n Example: \"Deployment/abcd\". \nNOTE 4: When the container infrastructure service is a Kubernetes® instance, the mcioName is the name field of the resource object.\n","type":"object","required":["mcioId","mcioName","mcioNamespace","vduId","cismId","mcioType","desiredInstances","availableInstances"],"properties":{"mcioId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioName":{"description":"Human readable name of this MCIO. See note 4.\n","type":"string"},"mcioNamespace":{"description":"Namespace of this MCIO.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cismId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioType":{"description":"The type of MCIO. Specific values, their semantics and associated MCIO types are defined in clause 5.5.4.9. Additional values are also permitted. See note 1.\n","type":"string","enum":["Deployment","Statefulset","DaemonSet"]},"desiredInstances":{"description":"Number of desired MCIO instances.\n","type":"integer"},"availableInstances":{"description":"Number of available MCIO instances.\n","type":"integer"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this MCIO instance uses. Shall be present when using in delegation mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfPaasServiceInfo":{"description":"Information on the PaaS Services assigned and used by the VNF instance.\n","type":"array","items":{"description":"This type provides input information about a PaaS Service that is used by a VNF instance. The PaasServiceInfo is comprised of various sets of information. Some information comes from the VNFD, other information comes from the PaaS Service assets provided by the NFVO to the VNFM, and other information is provided at runtime information about the usage of the PaaS Service.\n","type":"object","required":["id","paasServiceId","paasServiceType","paasServiceRequestId","paasServiceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceType":{"description":"The type of PaaS Service. The value of this attribute is expected to be matched against values of the registered PaaS Services in the PSR.","type":"string"},"paasServiceVersion":{"description":"A version.\n","type":"string"},"paasServiceRequestId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"paasServiceHandle":{"description":"This type provides information enabling the access and use of the PaaS Service by the VNF instance. The type and format of the handle depends on the form that the PaaS Service is formed.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"indicators":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"instantiate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"terminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"heal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"operate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"createSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"revertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeCurrentVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"recentVnfLcmOperationLinks":{"description":"Links to the most recent LCM operation occurrences related to this resource. See note 9.\n","type":"object","properties":{"recentVnfLcmOperation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmInstantiation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmTerminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmHeal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmOperate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmModifyInfo":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmCreateSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmRevertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmSelectDplMods":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}},"vnfcSnapshots":{"description":"Information about VNFC snapshots constituting this VNF snapshot.\n","type":"array","items":{"description":"This type represents a VNFC snapshot.\nNOTE 1:\tThe identifier of the compute snapshot resource is assigned during creation of a VNFC snapshot \n being returned from the VIM as output data in the response message of the individual resource \n operations. This attribute shall only be present for a VNFC snapshot that has been newly created \n by the VNFM as a result of the \"Create VNF snapshot task\".\nNOTE 2:\tThe identifier of the storage snapshot resource is assigned during creation of a VNFC snapshot being \n returned from the VIM as output data in the response message of the individual resource operations. \n This attribute shall only be present for a VNFC snapshot with an associated storage resource and that \n has been newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n","type":"object","required":["id","vnfcInstanceId","triggeredAt","vnfcResourceId"],"properties":{"id":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"vnfcInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"creationStartedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"creationFinishedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfcResourceInfoId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"computeSnapshotResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"storageSnapshotResources":{"description":"Mapping of the storage resources associated to the VNFC with the storage snapshot resources.\n","type":"array","items":{"type":"object","required":["storageResourceId"],"properties":{"storageResourceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"storageSnapshotResource":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"vnfStateSnapshotInfo":{"description":"This type represents information about VNF-specific state snapshot data.\n","type":"object","required":["checksum","isEncrypted"],"properties":{"checksum":{"description":"Cheksum description\n","type":"string"},"isEncrypted":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfStateSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"required":true},"VnfSnapshotInfoModificationRequest":{"description":"Parameters for the VNF snapshot information modification, as defined in clause 5.5.2.24.\n","content":{"application/merge-patch+json":{"schema":{"description":"This type represents attribute modifications for an \"Individual VNF snapshot\" resource, i.e. modifications\nto a resource representation based on the \"VnfSnapshotInfo\" data type. The attributes of \"VnfSnapshotInfo\"\nthat can be modified according to the provisions in clause 5.5.2.22 are included in the\n\"VnfSnapshotInfoModificationRequest\" data type.\n","type":"object","properties":{"vnfSnapshotPkgId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfSnapshot":{"description":"This type represents a VNF snapshot.\n","type":"object","required":["id","vnfInstanceId","triggeredAt","vnfdId","vnfInfo","vnfcSnapshots"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"creationStartedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"creationFinishedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstance":{"description":"This type represents a VNF instance.\nNOTE:\tClause B.3.2 provides examples illustrating the relationship among the different run-time \n information elements (CP, VL and link ports) used to represent the connectivity of a VNF.\n\nNOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist between \n the previous and the newly referred VNF package, i.e. when the new VNFD is changed with \n respect to the previous VNFD in other aspects than merely referencing to other VNF software \n images. In order to avoid misalignment of the VnfInstance with the current VNF's on-boarded \n VNF Package, the values of attributes in the VnfInstance that have corresponding attributes \n in the VNFD shall be kept in sync with the values in the VNFD.\nNOTE 2:\tETSI GS NFV-SOL 001 [14] specifies the structure and format of the VNFD based on TOSCA specifications. NOTE 3:\tVNF configurable properties are sometimes also referred to as configuration parameters applicable \n to a VNF. Some of these are set prior to instantiation and cannot be modified if the VNF is instantiated, \n some are set prior to instantiation (are part of initial configuration) and can be modified later, \n and others can be set only after instantiation. The applicability of certain configuration may \n depend on the VNF and the required operation of the VNF at a certain point in time.\nNOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes \n of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared in the VNFD with a defined \n initial value. The defined initial values can be declared in the VNFD, and/or, in case of \"metadata\", \n obtained from the \"CreateVnfRequest\" structure. Child attributes of \"vnfConfigurableProperties\", \n \"metadata\" and \"extensions\" that have no defined initial value shall not be created, in order to be \n consistent with the semantics of the JSON Merge Patch method (see IETF RFC 7396) that interprets null \n values as deletion request.\nNOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a \n multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same \n VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed \n multi-site VL instance (refer to clause 5.5.3.3).\nNOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity, they shall \n not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\nNOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing \n the trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\nNOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the \n VNF LCM operation explicitly indicates the scale level for the aspect.\nNOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n","type":"object","required":["id","vnfdId","vnfProvider","vnfProductName","vnfSoftwareVersion","vnfdVersion","instantiationState","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceName":{"description":"Name of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfInstanceDescription":{"description":"Human-readable description of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"Provider of the VNF and the VNFD. The value is copied from the VNFD.\n","type":"string"},"vnfProductName":{"description":"Name to identify the VNF Product. The value is copied from the VNFD.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vimConnectionInfo":{"description":"Information about VIM or CISM connections to be used for managing the resources for the VNF instance. The keys of the map, each of which identifies information about a particular VIM connection, are managed by the NFVO and referenced from other data structures via the \"vimConnectionId\" attribute. This attribute shall only be supported and present if - the resources of at least of the VNFCs are managed by a VIM and VNF-related resource management in direct mode is applicable. - the resources of at least of the VNFCs are managed by a CISM. This attribute can be modified with the PATCH method. If VIM connection information is provisioned to the VNFM by means outside the scope of the present document, the information in the \"vimConnectionInfo\" attribute provides necessary information for binding the VnfInstance representing the \"Individual VNF instance\" to the applicable VIM connection information used to perform resource management for the VNF instance. See also the definition of the \"VimConnectionInfo\" in clause 4.4.1.6.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"cirConnectionInfo":{"description":"Information about the CIR connection for managing OS container images for the VNF instance. Shall be present when all or part of the VNF is realized by a set of OS containers and shall be absent otherwise.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mciopRepositoryInfo":{"description":"Information about the MCIOP repository for the VNF instance. Shall be present when all or part of the VNF is realized by a set of OS containers and shall be absent otherwise. See note 1.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"certificateInfo":{"description":"This type provides input information related to certificate and certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateConfigurationInfo":{"description":"This type provides input information related to certificate management.\n","type":"object","required":["securityPolicy"],"properties":{"certificateBaseProfile":{"description":"Information for certificate profile.","type":"array","items":{"description":"NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\nThis type provides input information to override certificate base profile for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"description":"Issuer of certificates. See note.","type":"string"},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to the subject of the certificate.\nNOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of the certification target subject FQDN. Can be set empty when this certificate is used for encrypted communication using IP address. See note.\n","type":"string"},"organization":{"description":"Information of the certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of the certification target subject Country. See note.","type":"string"},"state":{"description":"Information of the certification target subject State. See note.","type":"string"},"locality":{"description":"Information of the certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of the certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"description":"Basic constraints of certificates. See note.","type":"string"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [14], clause 7.1.19.4). See note.\n","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}}},"securityPolicy":{"description":"Information for security policy to be satisfied for certificate.","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"number"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"number"}}}},"delegationSupportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"cmfInfo":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["id","endPoint","supportedProtocol"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"endPoint":{"description":"End point of CMF instance.","type":"object","properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocol":{"description":"Supported protocols by CMF instance.","type":"array","items":{"description":"Supported protocol by CMF instance.","type":"string","enum":["CMP","CMPv2","EST","SCEP"]}},"certificateChain":{"description":"Certificate chain that this CMF provides.","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"certificateContents":{"description":"Information for contents of issued certificates. The information contained in this attribute may be updated over time during the VNF LCM, e.g., certificate(s) renewal.\n","type":"array","items":{"description":"This type provides input information related to certificate content.\nNOTE: The CertificateDesc data type is defined in clause 7.1.19.2 of ETSI GS NFV IFA 011 [10].\n","type":"object","required":["id","certificateDescId","certificateType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"certificateType":{"description":"Type of this certificate.","type":"string","enum":["VNFCI_CERT","VNFOAM_CERT"]},"supportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"version":{"description":"A version.\n","type":"string"},"serialNumber":{"description":"Serial number of this certificate.","type":"integer"},"signatureAlgorithm":{"description":"Algorithm of this certificate's signature.","type":"string"},"issuer":{"description":"Issuer of this certificate.","type":"string"},"notBefore":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"notAfter":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"subject":{"description":"Subject of this certificate.","type":"string"},"publicKeyAlgorithm":{"description":"Algorithm of this certificate's public key.","type":"string"},"publicKey":{"description":"Public key of this certificate.","type":"string"},"certificateExtensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"instantiationState":{"description":"The instantiation state of the VNF. Permitted values: - NOT_INSTANTIATED: The VNF instance is terminated or not instantiated. - INSTANTIATED: The VNF instance is instantiated.\n","type":"string","enum":["NOT_INSTANTIATED","INSTANTIATED"]},"instantiatedVnfInfo":{"description":"Information specific to an instantiated VNF instance. This attribute shall be present if the instantiateState attribute value is INSTANTIATED.\n","type":"object","required":["flavourId","vnfState"],"properties":{"flavourId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfState":{"description":"STARTED: The VNF instance is up and running. STOPPED: The VNF instance has been shut down.\n","type":"string","enum":["STARTED","STOPPED"]},"vnfPowerState":{"description":"This type represents information about the power state of a VNF instance.\n","type":"object","required":["powerProfileId","name"],"properties":{"powerProfileId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Name of the power profile as provided in the VNFD.\n","type":"string"},"powerConsumptionInfo":{"description":"This type represents information about estimated power consumption of the resources associated with the power profile, as provided in the VNFD.\n","type":"object","required":["minPowerConsumption","maxPowerConsumption","averagePowerConsumption"],"properties":{"minPowerConsumption":{"description":"Minimum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"maxPowerConsumption":{"description":"Maximum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"averagePowerConsumption":{"description":"Average power consumption of this power profile. Unit is KW/h.\n","type":"integer"}}}}},"scaleStatus":{"description":"Scale status of the VNF, one entry per aspect. Represents for every scaling aspect how \"big\" the VNF has been scaled w.r.t. that aspect.\nThis attribute shall be present if the VNF supports scaling. See clause B.2 for an explanation of VNF scaling.\nFor an aspect that has not been deployed because the related deployableModule has not been selected, it indicates the scale level that has been requested in the instantiation or in a scaling operation, or, if none has been requested in any of them, the scale level applicable to the aspect based on the default instantiation level. See note 8.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"maxScaleLevels":{"description":"Maximum allowed scale levels of the VNF, one entry per aspect. This attribute shall be present if the VNF supports scaling.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"selectedDeployableModule":{"description":"References a currently selected deployable module, as defined in the VNFD, that has already completed the instantiation of its VNFCs.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceCapacityDefinition":{"description":"Shows current values of VDU attributes related to resource capacity, if different to the default values from the VNFD, as indicated in the (one or more) request(s) of all completed VNF LCM operation(s) that contain this attribute. If an attribute value has been modified multiple times, only the last value is shown. The values indicated in this attribute are applicable to all VNFC instances based on the VDU to which the resourceCapacityDefinition is related.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes.\nThe tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request.\nAt most one tag can be included when the data type is used in a VNF LCM operation request.\nWhen the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.\n","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced.\n","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute 'type' indicates OSCONTAINER and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource. See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resource property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for this virtual compute descriptor. The value is a numberthat indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) that indicates the valid vaues for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"extCpInfo":{"description":"Information about the external CPs exposed by the VNF instance. When trunking is enabled, the list of entries includes both, external CPs corresponding to parent ports of a trunk, and external CPs associated to sub-ports of a trunk.See note 7.\n","type":"array","items":{"description":"This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n","type":"object","required":["id","cpdId","cpConfigId","cpProtocolInfo"],"oneOf":[{"required":["associatedVnfcCpId"]},{"required":["associatedVipCpId"]},{"required":["associatedVnfVirtualLinkId"]}],"properties":{"id":{"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"},"cpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extLinkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"associatedVnfcCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVipCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVirtualCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVnfVirtualLinkId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 3 and 4.\nIt shall be present if the external CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNF CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpSecurityGroupInfo":{"description":"This type provides the list of active security group rules applied to an external CP instance. The type identifies which \"SecurityGroupRule\" specified in the VNFD are activated and the values of its attributes.\n","type":"object","required":["securityGroupRuleId","etherType","protocol","portRangeMin","portRangeMax"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"description":{"description":"Human readable description of the security group rule.\n","type":"string"},"etherType":{"description":"Indicates the protocol carried over the Ethernet layer. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"protocol":{"description":"Indicates the protocol carried over the IP layer. Permitted values: any protocol defined in the IANA protocol registry (refer to clause 9.10.1.2 ofd ETSI GS NFV-SOL 001 for further information).\n","type":"string"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule.\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule.\n","type":"integer"}}}}}},"vipCpInfo":{"description":"VIP CPs that are part of the VNF instance. Shall be present when that particular VIP CP of the VNFC instance is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","minItems":1,"items":{"description":"This type provides information related to virtual IP (VIP) CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["cpInstanceId","cpdId"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for layer 3. There may be one cpProtocolInfo for layer 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"associatedVnfcCpIds":{"description":"Identifiers of the VnfcCps that share the virtual IP address allocated to the VIP CP instance. See note.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualCpInfo":{"description":"Virtual CPs that are part of the VNF instance. Shall be present when a particular Virtual CP is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","items":{"description":"This type provides information related to a virtual CP instance of a VNF.\nNOTE 1: A consumer of the VNF LCM interface can learn the actual VNFC instances implementing the service accessible via the virtual CP instance by querying the \"vnfcResourceInfo\" from the \"InstantiatedVnfInfo\" \n and filtering by corresponding \"vduIds\" values.\nNOTE 2: The information can be omitted because it is already available as part of the external CP information in the VnfExtCpInfo structure.\n","type":"object","required":["cpInstanceId","cpdId","resourceHandle","vduIds"],"properties":{"cpInstanceId":{"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"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for each layer protocol supported. This attribute may be omitted if the virtual CP is exposed as an external CP. See note 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vduIds":{"description":"Reference to the VDU(s) which implement the service accessible via the virtual CP instance. See note 1.\n","type":"array","minItems":1,"items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"additionalServiceInfo":{"description":"Additional service identification information of the virtual CP instance.\n","type":"array","items":{"description":"This type provides additional service information of the virtual CP instance used to expose properties of the virtual CP to NFV-MANO.\nNOTE: This attribute shall only be present if additional information is needed to identify the service termination within the VNF, such as for example a URL path information in an HTTP request required \n to allow a single virtual CP IP address to be used for several HTTP based services that use the \n same port number.\n","type":"object","required":["portInfo"],"properties":{"portInfo":{"description":"Service port numbers exposed by the virtual CP instance.\n","minItems":1,"type":"array","items":{"description":"This type describes the service identifying port properties exposed by the virtual CP instance.\n","type":"object","required":["name","port","portConfigurable"],"properties":{"name":{"description":"The name of the port exposed by the virtual CP instance.\n","type":"string"},"protocol":{"description":"The L4 protocol for this port exposed by the virtual CP instance.\nPermitted values: - TCP - UDP - SCTP\n","type":"string","enum":["TCP","UDP","SCTP"]},"port":{"description":"The L4 port number exposed by the virtual CP instance.\n","type":"integer"},"portConfigurable":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"}}}},"serviceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"extVirtualLinkInfo":{"description":"Information about the external VLs the VNF instance is connected to.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extManagedVirtualLinkInfo":{"description":"Information about the externally-managed internal VLs of the VNF instance. See notes 5 and 6.\n","type":"array","items":{"description":"This type provides information about an externally-managed virtual link. Note: Both \"vnfLinkPort\" and \"vnfNetAttDefResource\" attributes can be present in an \"ExtManagedVirtualLinkInfo\" to indicate that a single internal virtual link is providing connectivity for both VM-based and container-based \n VNFCs.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPorts":{"description":"Link ports of this VL. See note.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"vnfNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL. See note.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"extManagedMultisiteVirtualLinkId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"routingResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"monitoringParameters":{"description":"Active monitoring parameters.\n","type":"array","items":{"description":"This type represents a monitoring parameter that is tracked by the VNFM,\n","type":"object","required":["id","performanceMetric"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human readable name of the monitoring parameter, as defined in the VNFD.\n","type":"string"},"performanceMetric":{"description":"Performance metric that is monitored. This attribute shall contain the related \"Measurement Name\" value as defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"}}}},"localizationLanguage":{"description":"Information about localization language of the VNF (includes e.g. strings in the VNFD). The localization languages supported by a VNF can be declared in the VNFD, and localization language selection can take place at instantiation time. The value shall comply with the format defined in IETF RFC 5646.\n","type":"string"},"vnfcResourceInfo":{"description":"Information about the virtualised compute and storage resources used by the VNFCs of the VNF instance.\n","type":"array","items":{"description":"This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure of\n information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n a) For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n b) For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\nNOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on \n TOSCA specifications.\nNOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an \n internal VL that exposes an external CP. A VNFC CP is \"exposed as\" an external \n CP if it is connected directly to an external VL.\nNOTE 3:\tThe information can be omitted because it is already available as part of the \n external CP information.\nNOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\"\n structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVnfc\" structure in the VNF LCM operation occurrence notifications\n or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\nNOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment\n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. \nNOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n","type":"object","required":["id","vduId","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResourceIds":{"description":"References to the VirtualStorage resources or references to Storage MCIOs. The value refers to a VirtualStorageResourceInfo item in the VnfInstance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcCpInfo":{"description":"CPs of the VNFC instance. Shall be present when that particular CP of the VNFC instance is exposed as an external CP of the VNF instance or is connected to an external CP of the VNF instance. See note 2. May be present otherwise. See note 7.\n","type":"array","items":{"type":"object","required":["id","cpdId"],"properties":{"id":{"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"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP. May be omitted if the VNFC CP is exposed as an external CP. See note 3.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"parentCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 5 and 6. It shall be present if the internal CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfVirtualLinkResourceInfo":{"description":"Information about the virtualised network resources used by the VLs of the VNF instance. See note 6.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by an internal VL instance in a VNF instance.\nNote: If only the value or the presence of this attribute is changed in the \"VnfVirtualLinkResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including\n a related \"AffectedVirtualLink\" structure in the VNF LCM operation occurrence notifications or the\n \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLinkPorts":{"description":"Links ports of this VL. Shall be present when the linkPort is used for external connectivity by the VNF (refer to VnfLinkPortInfo). May be present otherwise.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualStorageResourceInfo":{"description":"Information on the virtualised storage resource(s) used as storage for the VNF instance.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance.\nNote: If only the value or the presence of this attribute is changed in the \"VirtualStorageResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVirtualStorage\" structure in the VNF LCM operation occurrence\n notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","virtualStorageDescId","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mcioInfo":{"description":"Information on the MCIO(s) representing VNFC instance(s) realized by one or a set of OS containers and created from the same VDU for the VNF instance.\n","type":"array","items":{"description":"This type provides information about an MCIO representing the set of VNFC instances realized by one or a set of OS containers which have been created based on the same VDU. Within the CISM, an MCIO controller monitors the actual state of an MCIO representing the set of VNFC instances realized by one or a set of OS containers and compare it to the desired state For an MCIO related to a VDU that has the attribute isNumOfInstancesClusterBased set to FALSE the desired state is specified in the respective declarative descriptor. For an MCIO related to a VDU that has the attribute isNumOfInstancesClusterBased set to TRUE, the desired state is determined by the number of CIS-nodes in the cluster that fulfil the VDU requirements.as specified in the respective declarative descriptor. It triggers actions toward the CIS to align the actual to the desired state. Monitoring the actual state includes monitoring the number of MCIO instances available at any specific point in time. In addition, an MCIO controller maintains properties and runtime information on the MCIO instances which have been created based on the same VDU. The McioInfo data structure provides the runtime information on the MCIOs obtained from the MCIO controller.\nNOTE: There are different types of MCIOs. The set of VNFC instances based on the same VDU is represented by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type \n of MCIO, e.g. a POD.\n\nRuntime information of the set of OS containers realizing an individual VNFC instance is not part of the McioInfo data structure; such runtime information is provided in the ResourceHandle data structure referenced from the VnfcResourceInfo. The McioInfo does not provide runtime information of a constituent VNFC instance created based on a specific VDU.\nNOTE 1: The type of MCIO as specified in the declarative descriptor of the MCIO, and that can be read from the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the \n “kind” property of the declarative descriptor.\nNOTE 2: If the attribute additionalInfo is present, it may contain runtime information on the actual and desired state of the MCIO(s). \nNOTE 3: When the container infrastructure service is a Kubernetes® instance, the mcioId is the combined values from the kind and name fields of the Kubernetes resource object, separated by a slash. \n Example: \"Deployment/abcd\". \nNOTE 4: When the container infrastructure service is a Kubernetes® instance, the mcioName is the name field of the resource object.\n","type":"object","required":["mcioId","mcioName","mcioNamespace","vduId","cismId","mcioType","desiredInstances","availableInstances"],"properties":{"mcioId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioName":{"description":"Human readable name of this MCIO. See note 4.\n","type":"string"},"mcioNamespace":{"description":"Namespace of this MCIO.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cismId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioType":{"description":"The type of MCIO. Specific values, their semantics and associated MCIO types are defined in clause 5.5.4.9. Additional values are also permitted. See note 1.\n","type":"string","enum":["Deployment","Statefulset","DaemonSet"]},"desiredInstances":{"description":"Number of desired MCIO instances.\n","type":"integer"},"availableInstances":{"description":"Number of available MCIO instances.\n","type":"integer"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this MCIO instance uses. Shall be present when using in delegation mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfPaasServiceInfo":{"description":"Information on the PaaS Services assigned and used by the VNF instance.\n","type":"array","items":{"description":"This type provides input information about a PaaS Service that is used by a VNF instance. The PaasServiceInfo is comprised of various sets of information. Some information comes from the VNFD, other information comes from the PaaS Service assets provided by the NFVO to the VNFM, and other information is provided at runtime information about the usage of the PaaS Service.\n","type":"object","required":["id","paasServiceId","paasServiceType","paasServiceRequestId","paasServiceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceType":{"description":"The type of PaaS Service. The value of this attribute is expected to be matched against values of the registered PaaS Services in the PSR.","type":"string"},"paasServiceVersion":{"description":"A version.\n","type":"string"},"paasServiceRequestId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"paasServiceHandle":{"description":"This type provides information enabling the access and use of the PaaS Service by the VNF instance. The type and format of the handle depends on the form that the PaaS Service is formed.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"indicators":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"instantiate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"terminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"heal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"operate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"createSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"revertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeCurrentVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"recentVnfLcmOperationLinks":{"description":"Links to the most recent LCM operation occurrences related to this resource. See note 9.\n","type":"object","properties":{"recentVnfLcmOperation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmInstantiation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmTerminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmHeal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmOperate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmModifyInfo":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmCreateSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmRevertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmSelectDplMods":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}},"vnfcSnapshots":{"description":"Information about VNFC snapshots constituting this VNF snapshot.\n","type":"array","items":{"description":"This type represents a VNFC snapshot.\nNOTE 1:\tThe identifier of the compute snapshot resource is assigned during creation of a VNFC snapshot \n being returned from the VIM as output data in the response message of the individual resource \n operations. This attribute shall only be present for a VNFC snapshot that has been newly created \n by the VNFM as a result of the \"Create VNF snapshot task\".\nNOTE 2:\tThe identifier of the storage snapshot resource is assigned during creation of a VNFC snapshot being \n returned from the VIM as output data in the response message of the individual resource operations. \n This attribute shall only be present for a VNFC snapshot with an associated storage resource and that \n has been newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n","type":"object","required":["id","vnfcInstanceId","triggeredAt","vnfcResourceId"],"properties":{"id":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"vnfcInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"creationStartedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"creationFinishedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfcResourceInfoId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"computeSnapshotResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"storageSnapshotResources":{"description":"Mapping of the storage resources associated to the VNFC with the storage snapshot resources.\n","type":"array","items":{"type":"object","required":["storageResourceId"],"properties":{"storageResourceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"storageSnapshotResource":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"vnfStateSnapshotInfo":{"description":"This type represents information about VNF-specific state snapshot data.\n","type":"object","required":["checksum","isEncrypted"],"properties":{"checksum":{"description":"Cheksum description\n","type":"string"},"isEncrypted":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfStateSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"required":true}},"responses":{"VNFInstances.Post.201":{"description":"201 CREATED\n\nShall be returned when a new \"Individual VNF instance\" resource and\nthe associated VNF instance identifier washas been created successfully.\nThe response body shall contain a representation of the created VNF instance,\nas defined in clause 5.5.2.2.\nThe HTTP response shall include a \"Location\" HTTP header that contains the resource\nURI of the created VNF instance.\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a VNF instance.\nNOTE:\tClause B.3.2 provides examples illustrating the relationship among the different run-time \n information elements (CP, VL and link ports) used to represent the connectivity of a VNF.\n\nNOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist between \n the previous and the newly referred VNF package, i.e. when the new VNFD is changed with \n respect to the previous VNFD in other aspects than merely referencing to other VNF software \n images. In order to avoid misalignment of the VnfInstance with the current VNF's on-boarded \n VNF Package, the values of attributes in the VnfInstance that have corresponding attributes \n in the VNFD shall be kept in sync with the values in the VNFD.\nNOTE 2:\tETSI GS NFV-SOL 001 [14] specifies the structure and format of the VNFD based on TOSCA specifications. NOTE 3:\tVNF configurable properties are sometimes also referred to as configuration parameters applicable \n to a VNF. Some of these are set prior to instantiation and cannot be modified if the VNF is instantiated, \n some are set prior to instantiation (are part of initial configuration) and can be modified later, \n and others can be set only after instantiation. The applicability of certain configuration may \n depend on the VNF and the required operation of the VNF at a certain point in time.\nNOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes \n of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared in the VNFD with a defined \n initial value. The defined initial values can be declared in the VNFD, and/or, in case of \"metadata\", \n obtained from the \"CreateVnfRequest\" structure. Child attributes of \"vnfConfigurableProperties\", \n \"metadata\" and \"extensions\" that have no defined initial value shall not be created, in order to be \n consistent with the semantics of the JSON Merge Patch method (see IETF RFC 7396) that interprets null \n values as deletion request.\nNOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a \n multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same \n VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed \n multi-site VL instance (refer to clause 5.5.3.3).\nNOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity, they shall \n not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\nNOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing \n the trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\nNOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the \n VNF LCM operation explicitly indicates the scale level for the aspect.\nNOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n","type":"object","required":["id","vnfdId","vnfProvider","vnfProductName","vnfSoftwareVersion","vnfdVersion","instantiationState","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceName":{"description":"Name of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfInstanceDescription":{"description":"Human-readable description of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"Provider of the VNF and the VNFD. The value is copied from the VNFD.\n","type":"string"},"vnfProductName":{"description":"Name to identify the VNF Product. The value is copied from the VNFD.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vimConnectionInfo":{"description":"Information about VIM or CISM connections to be used for managing the resources for the VNF instance. The keys of the map, each of which identifies information about a particular VIM connection, are managed by the NFVO and referenced from other data structures via the \"vimConnectionId\" attribute. This attribute shall only be supported and present if - the resources of at least of the VNFCs are managed by a VIM and VNF-related resource management in direct mode is applicable. - the resources of at least of the VNFCs are managed by a CISM. This attribute can be modified with the PATCH method. If VIM connection information is provisioned to the VNFM by means outside the scope of the present document, the information in the \"vimConnectionInfo\" attribute provides necessary information for binding the VnfInstance representing the \"Individual VNF instance\" to the applicable VIM connection information used to perform resource management for the VNF instance. See also the definition of the \"VimConnectionInfo\" in clause 4.4.1.6.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"cirConnectionInfo":{"description":"Information about the CIR connection for managing OS container images for the VNF instance. Shall be present when all or part of the VNF is realized by a set of OS containers and shall be absent otherwise.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mciopRepositoryInfo":{"description":"Information about the MCIOP repository for the VNF instance. Shall be present when all or part of the VNF is realized by a set of OS containers and shall be absent otherwise. See note 1.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"certificateInfo":{"description":"This type provides input information related to certificate and certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateConfigurationInfo":{"description":"This type provides input information related to certificate management.\n","type":"object","required":["securityPolicy"],"properties":{"certificateBaseProfile":{"description":"Information for certificate profile.","type":"array","items":{"description":"NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\nThis type provides input information to override certificate base profile for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"description":"Issuer of certificates. See note.","type":"string"},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to the subject of the certificate.\nNOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of the certification target subject FQDN. Can be set empty when this certificate is used for encrypted communication using IP address. See note.\n","type":"string"},"organization":{"description":"Information of the certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of the certification target subject Country. See note.","type":"string"},"state":{"description":"Information of the certification target subject State. See note.","type":"string"},"locality":{"description":"Information of the certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of the certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"description":"Basic constraints of certificates. See note.","type":"string"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [14], clause 7.1.19.4). See note.\n","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}}},"securityPolicy":{"description":"Information for security policy to be satisfied for certificate.","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"number"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"number"}}}},"delegationSupportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"cmfInfo":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["id","endPoint","supportedProtocol"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"endPoint":{"description":"End point of CMF instance.","type":"object","properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocol":{"description":"Supported protocols by CMF instance.","type":"array","items":{"description":"Supported protocol by CMF instance.","type":"string","enum":["CMP","CMPv2","EST","SCEP"]}},"certificateChain":{"description":"Certificate chain that this CMF provides.","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"certificateContents":{"description":"Information for contents of issued certificates. The information contained in this attribute may be updated over time during the VNF LCM, e.g., certificate(s) renewal.\n","type":"array","items":{"description":"This type provides input information related to certificate content.\nNOTE: The CertificateDesc data type is defined in clause 7.1.19.2 of ETSI GS NFV IFA 011 [10].\n","type":"object","required":["id","certificateDescId","certificateType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"certificateType":{"description":"Type of this certificate.","type":"string","enum":["VNFCI_CERT","VNFOAM_CERT"]},"supportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"version":{"description":"A version.\n","type":"string"},"serialNumber":{"description":"Serial number of this certificate.","type":"integer"},"signatureAlgorithm":{"description":"Algorithm of this certificate's signature.","type":"string"},"issuer":{"description":"Issuer of this certificate.","type":"string"},"notBefore":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"notAfter":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"subject":{"description":"Subject of this certificate.","type":"string"},"publicKeyAlgorithm":{"description":"Algorithm of this certificate's public key.","type":"string"},"publicKey":{"description":"Public key of this certificate.","type":"string"},"certificateExtensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"instantiationState":{"description":"The instantiation state of the VNF. Permitted values: - NOT_INSTANTIATED: The VNF instance is terminated or not instantiated. - INSTANTIATED: The VNF instance is instantiated.\n","type":"string","enum":["NOT_INSTANTIATED","INSTANTIATED"]},"instantiatedVnfInfo":{"description":"Information specific to an instantiated VNF instance. This attribute shall be present if the instantiateState attribute value is INSTANTIATED.\n","type":"object","required":["flavourId","vnfState"],"properties":{"flavourId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfState":{"description":"STARTED: The VNF instance is up and running. STOPPED: The VNF instance has been shut down.\n","type":"string","enum":["STARTED","STOPPED"]},"vnfPowerState":{"description":"This type represents information about the power state of a VNF instance.\n","type":"object","required":["powerProfileId","name"],"properties":{"powerProfileId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Name of the power profile as provided in the VNFD.\n","type":"string"},"powerConsumptionInfo":{"description":"This type represents information about estimated power consumption of the resources associated with the power profile, as provided in the VNFD.\n","type":"object","required":["minPowerConsumption","maxPowerConsumption","averagePowerConsumption"],"properties":{"minPowerConsumption":{"description":"Minimum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"maxPowerConsumption":{"description":"Maximum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"averagePowerConsumption":{"description":"Average power consumption of this power profile. Unit is KW/h.\n","type":"integer"}}}}},"scaleStatus":{"description":"Scale status of the VNF, one entry per aspect. Represents for every scaling aspect how \"big\" the VNF has been scaled w.r.t. that aspect.\nThis attribute shall be present if the VNF supports scaling. See clause B.2 for an explanation of VNF scaling.\nFor an aspect that has not been deployed because the related deployableModule has not been selected, it indicates the scale level that has been requested in the instantiation or in a scaling operation, or, if none has been requested in any of them, the scale level applicable to the aspect based on the default instantiation level. See note 8.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"maxScaleLevels":{"description":"Maximum allowed scale levels of the VNF, one entry per aspect. This attribute shall be present if the VNF supports scaling.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"selectedDeployableModule":{"description":"References a currently selected deployable module, as defined in the VNFD, that has already completed the instantiation of its VNFCs.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceCapacityDefinition":{"description":"Shows current values of VDU attributes related to resource capacity, if different to the default values from the VNFD, as indicated in the (one or more) request(s) of all completed VNF LCM operation(s) that contain this attribute. If an attribute value has been modified multiple times, only the last value is shown. The values indicated in this attribute are applicable to all VNFC instances based on the VDU to which the resourceCapacityDefinition is related.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes.\nThe tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request.\nAt most one tag can be included when the data type is used in a VNF LCM operation request.\nWhen the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.\n","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced.\n","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute 'type' indicates OSCONTAINER and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource. See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resource property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for this virtual compute descriptor. The value is a numberthat indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) that indicates the valid vaues for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"extCpInfo":{"description":"Information about the external CPs exposed by the VNF instance. When trunking is enabled, the list of entries includes both, external CPs corresponding to parent ports of a trunk, and external CPs associated to sub-ports of a trunk.See note 7.\n","type":"array","items":{"description":"This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n","type":"object","required":["id","cpdId","cpConfigId","cpProtocolInfo"],"oneOf":[{"required":["associatedVnfcCpId"]},{"required":["associatedVipCpId"]},{"required":["associatedVnfVirtualLinkId"]}],"properties":{"id":{"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"},"cpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extLinkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"associatedVnfcCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVipCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVirtualCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVnfVirtualLinkId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 3 and 4.\nIt shall be present if the external CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNF CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpSecurityGroupInfo":{"description":"This type provides the list of active security group rules applied to an external CP instance. The type identifies which \"SecurityGroupRule\" specified in the VNFD are activated and the values of its attributes.\n","type":"object","required":["securityGroupRuleId","etherType","protocol","portRangeMin","portRangeMax"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"description":{"description":"Human readable description of the security group rule.\n","type":"string"},"etherType":{"description":"Indicates the protocol carried over the Ethernet layer. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"protocol":{"description":"Indicates the protocol carried over the IP layer. Permitted values: any protocol defined in the IANA protocol registry (refer to clause 9.10.1.2 ofd ETSI GS NFV-SOL 001 for further information).\n","type":"string"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule.\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule.\n","type":"integer"}}}}}},"vipCpInfo":{"description":"VIP CPs that are part of the VNF instance. Shall be present when that particular VIP CP of the VNFC instance is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","minItems":1,"items":{"description":"This type provides information related to virtual IP (VIP) CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["cpInstanceId","cpdId"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for layer 3. There may be one cpProtocolInfo for layer 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"associatedVnfcCpIds":{"description":"Identifiers of the VnfcCps that share the virtual IP address allocated to the VIP CP instance. See note.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualCpInfo":{"description":"Virtual CPs that are part of the VNF instance. Shall be present when a particular Virtual CP is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","items":{"description":"This type provides information related to a virtual CP instance of a VNF.\nNOTE 1: A consumer of the VNF LCM interface can learn the actual VNFC instances implementing the service accessible via the virtual CP instance by querying the \"vnfcResourceInfo\" from the \"InstantiatedVnfInfo\" \n and filtering by corresponding \"vduIds\" values.\nNOTE 2: The information can be omitted because it is already available as part of the external CP information in the VnfExtCpInfo structure.\n","type":"object","required":["cpInstanceId","cpdId","resourceHandle","vduIds"],"properties":{"cpInstanceId":{"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"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for each layer protocol supported. This attribute may be omitted if the virtual CP is exposed as an external CP. See note 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vduIds":{"description":"Reference to the VDU(s) which implement the service accessible via the virtual CP instance. See note 1.\n","type":"array","minItems":1,"items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"additionalServiceInfo":{"description":"Additional service identification information of the virtual CP instance.\n","type":"array","items":{"description":"This type provides additional service information of the virtual CP instance used to expose properties of the virtual CP to NFV-MANO.\nNOTE: This attribute shall only be present if additional information is needed to identify the service termination within the VNF, such as for example a URL path information in an HTTP request required \n to allow a single virtual CP IP address to be used for several HTTP based services that use the \n same port number.\n","type":"object","required":["portInfo"],"properties":{"portInfo":{"description":"Service port numbers exposed by the virtual CP instance.\n","minItems":1,"type":"array","items":{"description":"This type describes the service identifying port properties exposed by the virtual CP instance.\n","type":"object","required":["name","port","portConfigurable"],"properties":{"name":{"description":"The name of the port exposed by the virtual CP instance.\n","type":"string"},"protocol":{"description":"The L4 protocol for this port exposed by the virtual CP instance.\nPermitted values: - TCP - UDP - SCTP\n","type":"string","enum":["TCP","UDP","SCTP"]},"port":{"description":"The L4 port number exposed by the virtual CP instance.\n","type":"integer"},"portConfigurable":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"}}}},"serviceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"extVirtualLinkInfo":{"description":"Information about the external VLs the VNF instance is connected to.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extManagedVirtualLinkInfo":{"description":"Information about the externally-managed internal VLs of the VNF instance. See notes 5 and 6.\n","type":"array","items":{"description":"This type provides information about an externally-managed virtual link. Note: Both \"vnfLinkPort\" and \"vnfNetAttDefResource\" attributes can be present in an \"ExtManagedVirtualLinkInfo\" to indicate that a single internal virtual link is providing connectivity for both VM-based and container-based \n VNFCs.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPorts":{"description":"Link ports of this VL. See note.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"vnfNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL. See note.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"extManagedMultisiteVirtualLinkId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"routingResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"monitoringParameters":{"description":"Active monitoring parameters.\n","type":"array","items":{"description":"This type represents a monitoring parameter that is tracked by the VNFM,\n","type":"object","required":["id","performanceMetric"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human readable name of the monitoring parameter, as defined in the VNFD.\n","type":"string"},"performanceMetric":{"description":"Performance metric that is monitored. This attribute shall contain the related \"Measurement Name\" value as defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"}}}},"localizationLanguage":{"description":"Information about localization language of the VNF (includes e.g. strings in the VNFD). The localization languages supported by a VNF can be declared in the VNFD, and localization language selection can take place at instantiation time. The value shall comply with the format defined in IETF RFC 5646.\n","type":"string"},"vnfcResourceInfo":{"description":"Information about the virtualised compute and storage resources used by the VNFCs of the VNF instance.\n","type":"array","items":{"description":"This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure of\n information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n a) For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n b) For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\nNOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on \n TOSCA specifications.\nNOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an \n internal VL that exposes an external CP. A VNFC CP is \"exposed as\" an external \n CP if it is connected directly to an external VL.\nNOTE 3:\tThe information can be omitted because it is already available as part of the \n external CP information.\nNOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\"\n structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVnfc\" structure in the VNF LCM operation occurrence notifications\n or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\nNOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment\n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. \nNOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n","type":"object","required":["id","vduId","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResourceIds":{"description":"References to the VirtualStorage resources or references to Storage MCIOs. The value refers to a VirtualStorageResourceInfo item in the VnfInstance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcCpInfo":{"description":"CPs of the VNFC instance. Shall be present when that particular CP of the VNFC instance is exposed as an external CP of the VNF instance or is connected to an external CP of the VNF instance. See note 2. May be present otherwise. See note 7.\n","type":"array","items":{"type":"object","required":["id","cpdId"],"properties":{"id":{"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"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP. May be omitted if the VNFC CP is exposed as an external CP. See note 3.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"parentCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 5 and 6. It shall be present if the internal CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfVirtualLinkResourceInfo":{"description":"Information about the virtualised network resources used by the VLs of the VNF instance. See note 6.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by an internal VL instance in a VNF instance.\nNote: If only the value or the presence of this attribute is changed in the \"VnfVirtualLinkResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including\n a related \"AffectedVirtualLink\" structure in the VNF LCM operation occurrence notifications or the\n \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLinkPorts":{"description":"Links ports of this VL. Shall be present when the linkPort is used for external connectivity by the VNF (refer to VnfLinkPortInfo). May be present otherwise.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualStorageResourceInfo":{"description":"Information on the virtualised storage resource(s) used as storage for the VNF instance.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance.\nNote: If only the value or the presence of this attribute is changed in the \"VirtualStorageResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVirtualStorage\" structure in the VNF LCM operation occurrence\n notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","virtualStorageDescId","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mcioInfo":{"description":"Information on the MCIO(s) representing VNFC instance(s) realized by one or a set of OS containers and created from the same VDU for the VNF instance.\n","type":"array","items":{"description":"This type provides information about an MCIO representing the set of VNFC instances realized by one or a set of OS containers which have been created based on the same VDU. Within the CISM, an MCIO controller monitors the actual state of an MCIO representing the set of VNFC instances realized by one or a set of OS containers and compare it to the desired state For an MCIO related to a VDU that has the attribute isNumOfInstancesClusterBased set to FALSE the desired state is specified in the respective declarative descriptor. For an MCIO related to a VDU that has the attribute isNumOfInstancesClusterBased set to TRUE, the desired state is determined by the number of CIS-nodes in the cluster that fulfil the VDU requirements.as specified in the respective declarative descriptor. It triggers actions toward the CIS to align the actual to the desired state. Monitoring the actual state includes monitoring the number of MCIO instances available at any specific point in time. In addition, an MCIO controller maintains properties and runtime information on the MCIO instances which have been created based on the same VDU. The McioInfo data structure provides the runtime information on the MCIOs obtained from the MCIO controller.\nNOTE: There are different types of MCIOs. The set of VNFC instances based on the same VDU is represented by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type \n of MCIO, e.g. a POD.\n\nRuntime information of the set of OS containers realizing an individual VNFC instance is not part of the McioInfo data structure; such runtime information is provided in the ResourceHandle data structure referenced from the VnfcResourceInfo. The McioInfo does not provide runtime information of a constituent VNFC instance created based on a specific VDU.\nNOTE 1: The type of MCIO as specified in the declarative descriptor of the MCIO, and that can be read from the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the \n “kind” property of the declarative descriptor.\nNOTE 2: If the attribute additionalInfo is present, it may contain runtime information on the actual and desired state of the MCIO(s). \nNOTE 3: When the container infrastructure service is a Kubernetes® instance, the mcioId is the combined values from the kind and name fields of the Kubernetes resource object, separated by a slash. \n Example: \"Deployment/abcd\". \nNOTE 4: When the container infrastructure service is a Kubernetes® instance, the mcioName is the name field of the resource object.\n","type":"object","required":["mcioId","mcioName","mcioNamespace","vduId","cismId","mcioType","desiredInstances","availableInstances"],"properties":{"mcioId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioName":{"description":"Human readable name of this MCIO. See note 4.\n","type":"string"},"mcioNamespace":{"description":"Namespace of this MCIO.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cismId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioType":{"description":"The type of MCIO. Specific values, their semantics and associated MCIO types are defined in clause 5.5.4.9. Additional values are also permitted. See note 1.\n","type":"string","enum":["Deployment","Statefulset","DaemonSet"]},"desiredInstances":{"description":"Number of desired MCIO instances.\n","type":"integer"},"availableInstances":{"description":"Number of available MCIO instances.\n","type":"integer"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this MCIO instance uses. Shall be present when using in delegation mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfPaasServiceInfo":{"description":"Information on the PaaS Services assigned and used by the VNF instance.\n","type":"array","items":{"description":"This type provides input information about a PaaS Service that is used by a VNF instance. The PaasServiceInfo is comprised of various sets of information. Some information comes from the VNFD, other information comes from the PaaS Service assets provided by the NFVO to the VNFM, and other information is provided at runtime information about the usage of the PaaS Service.\n","type":"object","required":["id","paasServiceId","paasServiceType","paasServiceRequestId","paasServiceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceType":{"description":"The type of PaaS Service. The value of this attribute is expected to be matched against values of the registered PaaS Services in the PSR.","type":"string"},"paasServiceVersion":{"description":"A version.\n","type":"string"},"paasServiceRequestId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"paasServiceHandle":{"description":"This type provides information enabling the access and use of the PaaS Service by the VNF instance. The type and format of the handle depends on the form that the PaaS Service is formed.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"indicators":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"instantiate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"terminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"heal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"operate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"createSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"revertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeCurrentVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"recentVnfLcmOperationLinks":{"description":"Links to the most recent LCM operation occurrences related to this resource. See note 9.\n","type":"object","properties":{"recentVnfLcmOperation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmInstantiation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmTerminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmHeal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmOperate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmModifyInfo":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmCreateSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmRevertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmSelectDplMods":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"VNFInstances.Post.422":{"description":"422 Unprocessable Content\n\nShall be returned upon the following error: The content\ntype of the message content is supported and the message\ncontent of a request contains syntactically correct data\nbut the data cannot be processed.\nThe general cause for this error and its handling is\nspecified in clause 6.4 of ETSI GS NFV-SOL 013 [8],\nincluding rules for the presence of the response body.\nSpecifically in case of this resource, the response\ncode 422 shall also be returned if the VNF package\nreferenced by the \"vnfdId\" attribute in the\n\"CreateVnfRequest\" structure is not in the \"ENABLED\"\nstate or does not exist. In this case, the \"detail\"\nattribute in the \"ProblemDetails\" structure shall convey\nmore information about the error\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"VNFInstances.Get.200":{"description":"200 OK\n\nShall be returned when information about zero or more VNF instances has been queried successfully.\nThe response body shall contain in an array the representations of zero or more VNF instances,\nas defined in clause 5.5.2.2.\nIf the \"filter\" URI parameter or one of the \"all_fields\", \"fields\" (if supported), \"exclude_fields\"\n(if supported) or \"exclude_default\" URI parameters was supplied in the request, the data in the response\nbody shall have been transformed according to the rules specified in clauses 5.2.2 and 5.3.2 of\nETSI GS NFV-SOL 013, respectively.\nIf the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013\nfor this resource, inclusion of the Link HTTP header in this response shall follow the provisions\nin clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a VNF instance.\nNOTE:\tClause B.3.2 provides examples illustrating the relationship among the different run-time \n information elements (CP, VL and link ports) used to represent the connectivity of a VNF.\n\nNOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist between \n the previous and the newly referred VNF package, i.e. when the new VNFD is changed with \n respect to the previous VNFD in other aspects than merely referencing to other VNF software \n images. In order to avoid misalignment of the VnfInstance with the current VNF's on-boarded \n VNF Package, the values of attributes in the VnfInstance that have corresponding attributes \n in the VNFD shall be kept in sync with the values in the VNFD.\nNOTE 2:\tETSI GS NFV-SOL 001 [14] specifies the structure and format of the VNFD based on TOSCA specifications. NOTE 3:\tVNF configurable properties are sometimes also referred to as configuration parameters applicable \n to a VNF. Some of these are set prior to instantiation and cannot be modified if the VNF is instantiated, \n some are set prior to instantiation (are part of initial configuration) and can be modified later, \n and others can be set only after instantiation. The applicability of certain configuration may \n depend on the VNF and the required operation of the VNF at a certain point in time.\nNOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes \n of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared in the VNFD with a defined \n initial value. The defined initial values can be declared in the VNFD, and/or, in case of \"metadata\", \n obtained from the \"CreateVnfRequest\" structure. Child attributes of \"vnfConfigurableProperties\", \n \"metadata\" and \"extensions\" that have no defined initial value shall not be created, in order to be \n consistent with the semantics of the JSON Merge Patch method (see IETF RFC 7396) that interprets null \n values as deletion request.\nNOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a \n multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same \n VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed \n multi-site VL instance (refer to clause 5.5.3.3).\nNOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity, they shall \n not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\nNOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing \n the trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\nNOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the \n VNF LCM operation explicitly indicates the scale level for the aspect.\nNOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n","type":"object","required":["id","vnfdId","vnfProvider","vnfProductName","vnfSoftwareVersion","vnfdVersion","instantiationState","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceName":{"description":"Name of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfInstanceDescription":{"description":"Human-readable description of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"Provider of the VNF and the VNFD. The value is copied from the VNFD.\n","type":"string"},"vnfProductName":{"description":"Name to identify the VNF Product. The value is copied from the VNFD.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vimConnectionInfo":{"description":"Information about VIM or CISM connections to be used for managing the resources for the VNF instance. The keys of the map, each of which identifies information about a particular VIM connection, are managed by the NFVO and referenced from other data structures via the \"vimConnectionId\" attribute. This attribute shall only be supported and present if - the resources of at least of the VNFCs are managed by a VIM and VNF-related resource management in direct mode is applicable. - the resources of at least of the VNFCs are managed by a CISM. This attribute can be modified with the PATCH method. If VIM connection information is provisioned to the VNFM by means outside the scope of the present document, the information in the \"vimConnectionInfo\" attribute provides necessary information for binding the VnfInstance representing the \"Individual VNF instance\" to the applicable VIM connection information used to perform resource management for the VNF instance. See also the definition of the \"VimConnectionInfo\" in clause 4.4.1.6.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"cirConnectionInfo":{"description":"Information about the CIR connection for managing OS container images for the VNF instance. Shall be present when all or part of the VNF is realized by a set of OS containers and shall be absent otherwise.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mciopRepositoryInfo":{"description":"Information about the MCIOP repository for the VNF instance. Shall be present when all or part of the VNF is realized by a set of OS containers and shall be absent otherwise. See note 1.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"certificateInfo":{"description":"This type provides input information related to certificate and certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateConfigurationInfo":{"description":"This type provides input information related to certificate management.\n","type":"object","required":["securityPolicy"],"properties":{"certificateBaseProfile":{"description":"Information for certificate profile.","type":"array","items":{"description":"NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\nThis type provides input information to override certificate base profile for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"description":"Issuer of certificates. See note.","type":"string"},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to the subject of the certificate.\nNOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of the certification target subject FQDN. Can be set empty when this certificate is used for encrypted communication using IP address. See note.\n","type":"string"},"organization":{"description":"Information of the certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of the certification target subject Country. See note.","type":"string"},"state":{"description":"Information of the certification target subject State. See note.","type":"string"},"locality":{"description":"Information of the certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of the certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"description":"Basic constraints of certificates. See note.","type":"string"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [14], clause 7.1.19.4). See note.\n","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}}},"securityPolicy":{"description":"Information for security policy to be satisfied for certificate.","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"number"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"number"}}}},"delegationSupportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"cmfInfo":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["id","endPoint","supportedProtocol"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"endPoint":{"description":"End point of CMF instance.","type":"object","properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocol":{"description":"Supported protocols by CMF instance.","type":"array","items":{"description":"Supported protocol by CMF instance.","type":"string","enum":["CMP","CMPv2","EST","SCEP"]}},"certificateChain":{"description":"Certificate chain that this CMF provides.","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"certificateContents":{"description":"Information for contents of issued certificates. The information contained in this attribute may be updated over time during the VNF LCM, e.g., certificate(s) renewal.\n","type":"array","items":{"description":"This type provides input information related to certificate content.\nNOTE: The CertificateDesc data type is defined in clause 7.1.19.2 of ETSI GS NFV IFA 011 [10].\n","type":"object","required":["id","certificateDescId","certificateType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"certificateType":{"description":"Type of this certificate.","type":"string","enum":["VNFCI_CERT","VNFOAM_CERT"]},"supportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"version":{"description":"A version.\n","type":"string"},"serialNumber":{"description":"Serial number of this certificate.","type":"integer"},"signatureAlgorithm":{"description":"Algorithm of this certificate's signature.","type":"string"},"issuer":{"description":"Issuer of this certificate.","type":"string"},"notBefore":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"notAfter":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"subject":{"description":"Subject of this certificate.","type":"string"},"publicKeyAlgorithm":{"description":"Algorithm of this certificate's public key.","type":"string"},"publicKey":{"description":"Public key of this certificate.","type":"string"},"certificateExtensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"instantiationState":{"description":"The instantiation state of the VNF. Permitted values: - NOT_INSTANTIATED: The VNF instance is terminated or not instantiated. - INSTANTIATED: The VNF instance is instantiated.\n","type":"string","enum":["NOT_INSTANTIATED","INSTANTIATED"]},"instantiatedVnfInfo":{"description":"Information specific to an instantiated VNF instance. This attribute shall be present if the instantiateState attribute value is INSTANTIATED.\n","type":"object","required":["flavourId","vnfState"],"properties":{"flavourId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfState":{"description":"STARTED: The VNF instance is up and running. STOPPED: The VNF instance has been shut down.\n","type":"string","enum":["STARTED","STOPPED"]},"vnfPowerState":{"description":"This type represents information about the power state of a VNF instance.\n","type":"object","required":["powerProfileId","name"],"properties":{"powerProfileId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Name of the power profile as provided in the VNFD.\n","type":"string"},"powerConsumptionInfo":{"description":"This type represents information about estimated power consumption of the resources associated with the power profile, as provided in the VNFD.\n","type":"object","required":["minPowerConsumption","maxPowerConsumption","averagePowerConsumption"],"properties":{"minPowerConsumption":{"description":"Minimum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"maxPowerConsumption":{"description":"Maximum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"averagePowerConsumption":{"description":"Average power consumption of this power profile. Unit is KW/h.\n","type":"integer"}}}}},"scaleStatus":{"description":"Scale status of the VNF, one entry per aspect. Represents for every scaling aspect how \"big\" the VNF has been scaled w.r.t. that aspect.\nThis attribute shall be present if the VNF supports scaling. See clause B.2 for an explanation of VNF scaling.\nFor an aspect that has not been deployed because the related deployableModule has not been selected, it indicates the scale level that has been requested in the instantiation or in a scaling operation, or, if none has been requested in any of them, the scale level applicable to the aspect based on the default instantiation level. See note 8.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"maxScaleLevels":{"description":"Maximum allowed scale levels of the VNF, one entry per aspect. This attribute shall be present if the VNF supports scaling.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"selectedDeployableModule":{"description":"References a currently selected deployable module, as defined in the VNFD, that has already completed the instantiation of its VNFCs.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceCapacityDefinition":{"description":"Shows current values of VDU attributes related to resource capacity, if different to the default values from the VNFD, as indicated in the (one or more) request(s) of all completed VNF LCM operation(s) that contain this attribute. If an attribute value has been modified multiple times, only the last value is shown. The values indicated in this attribute are applicable to all VNFC instances based on the VDU to which the resourceCapacityDefinition is related.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes.\nThe tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request.\nAt most one tag can be included when the data type is used in a VNF LCM operation request.\nWhen the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.\n","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced.\n","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute 'type' indicates OSCONTAINER and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource. See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resource property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for this virtual compute descriptor. The value is a numberthat indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) that indicates the valid vaues for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"extCpInfo":{"description":"Information about the external CPs exposed by the VNF instance. When trunking is enabled, the list of entries includes both, external CPs corresponding to parent ports of a trunk, and external CPs associated to sub-ports of a trunk.See note 7.\n","type":"array","items":{"description":"This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n","type":"object","required":["id","cpdId","cpConfigId","cpProtocolInfo"],"oneOf":[{"required":["associatedVnfcCpId"]},{"required":["associatedVipCpId"]},{"required":["associatedVnfVirtualLinkId"]}],"properties":{"id":{"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"},"cpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extLinkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"associatedVnfcCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVipCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVirtualCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVnfVirtualLinkId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 3 and 4.\nIt shall be present if the external CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNF CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpSecurityGroupInfo":{"description":"This type provides the list of active security group rules applied to an external CP instance. The type identifies which \"SecurityGroupRule\" specified in the VNFD are activated and the values of its attributes.\n","type":"object","required":["securityGroupRuleId","etherType","protocol","portRangeMin","portRangeMax"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"description":{"description":"Human readable description of the security group rule.\n","type":"string"},"etherType":{"description":"Indicates the protocol carried over the Ethernet layer. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"protocol":{"description":"Indicates the protocol carried over the IP layer. Permitted values: any protocol defined in the IANA protocol registry (refer to clause 9.10.1.2 ofd ETSI GS NFV-SOL 001 for further information).\n","type":"string"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule.\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule.\n","type":"integer"}}}}}},"vipCpInfo":{"description":"VIP CPs that are part of the VNF instance. Shall be present when that particular VIP CP of the VNFC instance is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","minItems":1,"items":{"description":"This type provides information related to virtual IP (VIP) CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["cpInstanceId","cpdId"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for layer 3. There may be one cpProtocolInfo for layer 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"associatedVnfcCpIds":{"description":"Identifiers of the VnfcCps that share the virtual IP address allocated to the VIP CP instance. See note.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualCpInfo":{"description":"Virtual CPs that are part of the VNF instance. Shall be present when a particular Virtual CP is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","items":{"description":"This type provides information related to a virtual CP instance of a VNF.\nNOTE 1: A consumer of the VNF LCM interface can learn the actual VNFC instances implementing the service accessible via the virtual CP instance by querying the \"vnfcResourceInfo\" from the \"InstantiatedVnfInfo\" \n and filtering by corresponding \"vduIds\" values.\nNOTE 2: The information can be omitted because it is already available as part of the external CP information in the VnfExtCpInfo structure.\n","type":"object","required":["cpInstanceId","cpdId","resourceHandle","vduIds"],"properties":{"cpInstanceId":{"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"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for each layer protocol supported. This attribute may be omitted if the virtual CP is exposed as an external CP. See note 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vduIds":{"description":"Reference to the VDU(s) which implement the service accessible via the virtual CP instance. See note 1.\n","type":"array","minItems":1,"items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"additionalServiceInfo":{"description":"Additional service identification information of the virtual CP instance.\n","type":"array","items":{"description":"This type provides additional service information of the virtual CP instance used to expose properties of the virtual CP to NFV-MANO.\nNOTE: This attribute shall only be present if additional information is needed to identify the service termination within the VNF, such as for example a URL path information in an HTTP request required \n to allow a single virtual CP IP address to be used for several HTTP based services that use the \n same port number.\n","type":"object","required":["portInfo"],"properties":{"portInfo":{"description":"Service port numbers exposed by the virtual CP instance.\n","minItems":1,"type":"array","items":{"description":"This type describes the service identifying port properties exposed by the virtual CP instance.\n","type":"object","required":["name","port","portConfigurable"],"properties":{"name":{"description":"The name of the port exposed by the virtual CP instance.\n","type":"string"},"protocol":{"description":"The L4 protocol for this port exposed by the virtual CP instance.\nPermitted values: - TCP - UDP - SCTP\n","type":"string","enum":["TCP","UDP","SCTP"]},"port":{"description":"The L4 port number exposed by the virtual CP instance.\n","type":"integer"},"portConfigurable":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"}}}},"serviceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"extVirtualLinkInfo":{"description":"Information about the external VLs the VNF instance is connected to.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extManagedVirtualLinkInfo":{"description":"Information about the externally-managed internal VLs of the VNF instance. See notes 5 and 6.\n","type":"array","items":{"description":"This type provides information about an externally-managed virtual link. Note: Both \"vnfLinkPort\" and \"vnfNetAttDefResource\" attributes can be present in an \"ExtManagedVirtualLinkInfo\" to indicate that a single internal virtual link is providing connectivity for both VM-based and container-based \n VNFCs.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPorts":{"description":"Link ports of this VL. See note.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"vnfNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL. See note.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"extManagedMultisiteVirtualLinkId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"routingResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"monitoringParameters":{"description":"Active monitoring parameters.\n","type":"array","items":{"description":"This type represents a monitoring parameter that is tracked by the VNFM,\n","type":"object","required":["id","performanceMetric"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human readable name of the monitoring parameter, as defined in the VNFD.\n","type":"string"},"performanceMetric":{"description":"Performance metric that is monitored. This attribute shall contain the related \"Measurement Name\" value as defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"}}}},"localizationLanguage":{"description":"Information about localization language of the VNF (includes e.g. strings in the VNFD). The localization languages supported by a VNF can be declared in the VNFD, and localization language selection can take place at instantiation time. The value shall comply with the format defined in IETF RFC 5646.\n","type":"string"},"vnfcResourceInfo":{"description":"Information about the virtualised compute and storage resources used by the VNFCs of the VNF instance.\n","type":"array","items":{"description":"This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure of\n information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n a) For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n b) For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\nNOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on \n TOSCA specifications.\nNOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an \n internal VL that exposes an external CP. A VNFC CP is \"exposed as\" an external \n CP if it is connected directly to an external VL.\nNOTE 3:\tThe information can be omitted because it is already available as part of the \n external CP information.\nNOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\"\n structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVnfc\" structure in the VNF LCM operation occurrence notifications\n or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\nNOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment\n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. \nNOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n","type":"object","required":["id","vduId","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResourceIds":{"description":"References to the VirtualStorage resources or references to Storage MCIOs. The value refers to a VirtualStorageResourceInfo item in the VnfInstance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcCpInfo":{"description":"CPs of the VNFC instance. Shall be present when that particular CP of the VNFC instance is exposed as an external CP of the VNF instance or is connected to an external CP of the VNF instance. See note 2. May be present otherwise. See note 7.\n","type":"array","items":{"type":"object","required":["id","cpdId"],"properties":{"id":{"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"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP. May be omitted if the VNFC CP is exposed as an external CP. See note 3.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"parentCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 5 and 6. It shall be present if the internal CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfVirtualLinkResourceInfo":{"description":"Information about the virtualised network resources used by the VLs of the VNF instance. See note 6.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by an internal VL instance in a VNF instance.\nNote: If only the value or the presence of this attribute is changed in the \"VnfVirtualLinkResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including\n a related \"AffectedVirtualLink\" structure in the VNF LCM operation occurrence notifications or the\n \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLinkPorts":{"description":"Links ports of this VL. Shall be present when the linkPort is used for external connectivity by the VNF (refer to VnfLinkPortInfo). May be present otherwise.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualStorageResourceInfo":{"description":"Information on the virtualised storage resource(s) used as storage for the VNF instance.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance.\nNote: If only the value or the presence of this attribute is changed in the \"VirtualStorageResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVirtualStorage\" structure in the VNF LCM operation occurrence\n notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","virtualStorageDescId","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mcioInfo":{"description":"Information on the MCIO(s) representing VNFC instance(s) realized by one or a set of OS containers and created from the same VDU for the VNF instance.\n","type":"array","items":{"description":"This type provides information about an MCIO representing the set of VNFC instances realized by one or a set of OS containers which have been created based on the same VDU. Within the CISM, an MCIO controller monitors the actual state of an MCIO representing the set of VNFC instances realized by one or a set of OS containers and compare it to the desired state For an MCIO related to a VDU that has the attribute isNumOfInstancesClusterBased set to FALSE the desired state is specified in the respective declarative descriptor. For an MCIO related to a VDU that has the attribute isNumOfInstancesClusterBased set to TRUE, the desired state is determined by the number of CIS-nodes in the cluster that fulfil the VDU requirements.as specified in the respective declarative descriptor. It triggers actions toward the CIS to align the actual to the desired state. Monitoring the actual state includes monitoring the number of MCIO instances available at any specific point in time. In addition, an MCIO controller maintains properties and runtime information on the MCIO instances which have been created based on the same VDU. The McioInfo data structure provides the runtime information on the MCIOs obtained from the MCIO controller.\nNOTE: There are different types of MCIOs. The set of VNFC instances based on the same VDU is represented by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type \n of MCIO, e.g. a POD.\n\nRuntime information of the set of OS containers realizing an individual VNFC instance is not part of the McioInfo data structure; such runtime information is provided in the ResourceHandle data structure referenced from the VnfcResourceInfo. The McioInfo does not provide runtime information of a constituent VNFC instance created based on a specific VDU.\nNOTE 1: The type of MCIO as specified in the declarative descriptor of the MCIO, and that can be read from the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the \n “kind” property of the declarative descriptor.\nNOTE 2: If the attribute additionalInfo is present, it may contain runtime information on the actual and desired state of the MCIO(s). \nNOTE 3: When the container infrastructure service is a Kubernetes® instance, the mcioId is the combined values from the kind and name fields of the Kubernetes resource object, separated by a slash. \n Example: \"Deployment/abcd\". \nNOTE 4: When the container infrastructure service is a Kubernetes® instance, the mcioName is the name field of the resource object.\n","type":"object","required":["mcioId","mcioName","mcioNamespace","vduId","cismId","mcioType","desiredInstances","availableInstances"],"properties":{"mcioId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioName":{"description":"Human readable name of this MCIO. See note 4.\n","type":"string"},"mcioNamespace":{"description":"Namespace of this MCIO.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cismId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioType":{"description":"The type of MCIO. Specific values, their semantics and associated MCIO types are defined in clause 5.5.4.9. Additional values are also permitted. See note 1.\n","type":"string","enum":["Deployment","Statefulset","DaemonSet"]},"desiredInstances":{"description":"Number of desired MCIO instances.\n","type":"integer"},"availableInstances":{"description":"Number of available MCIO instances.\n","type":"integer"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this MCIO instance uses. Shall be present when using in delegation mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfPaasServiceInfo":{"description":"Information on the PaaS Services assigned and used by the VNF instance.\n","type":"array","items":{"description":"This type provides input information about a PaaS Service that is used by a VNF instance. The PaasServiceInfo is comprised of various sets of information. Some information comes from the VNFD, other information comes from the PaaS Service assets provided by the NFVO to the VNFM, and other information is provided at runtime information about the usage of the PaaS Service.\n","type":"object","required":["id","paasServiceId","paasServiceType","paasServiceRequestId","paasServiceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceType":{"description":"The type of PaaS Service. The value of this attribute is expected to be matched against values of the registered PaaS Services in the PSR.","type":"string"},"paasServiceVersion":{"description":"A version.\n","type":"string"},"paasServiceRequestId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"paasServiceHandle":{"description":"This type provides information enabling the access and use of the PaaS Service by the VNF instance. The type and format of the handle depends on the form that the PaaS Service is formed.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"indicators":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"instantiate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"terminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"heal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"operate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"createSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"revertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeCurrentVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"recentVnfLcmOperationLinks":{"description":"Links to the most recent LCM operation occurrences related to this resource. See note 9.\n","type":"object","properties":{"recentVnfLcmOperation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmInstantiation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmTerminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmHeal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmOperate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmModifyInfo":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmCreateSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmRevertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmSelectDplMods":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"IndividualVnfInstance.Get.200":{"description":"200 OK\n\nShall be returned when information about an individual VNF instance has been read successfully.\nThe response body shall contain a representation of the VNF instance, as defined in clause 5.5.2.2.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"ETag":{"description":"Used to provide the current entity-tag for the selected resource representation. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string"}},"Last-Modified":{"description":"Used to provide a timestamp indicating the date and time at which the server believes the selected resource representation was last modified. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string","format":"date-time"}}},"content":{"application/json":{"schema":{"description":"This type represents a VNF instance.\nNOTE:\tClause B.3.2 provides examples illustrating the relationship among the different run-time \n information elements (CP, VL and link ports) used to represent the connectivity of a VNF.\n\nNOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist between \n the previous and the newly referred VNF package, i.e. when the new VNFD is changed with \n respect to the previous VNFD in other aspects than merely referencing to other VNF software \n images. In order to avoid misalignment of the VnfInstance with the current VNF's on-boarded \n VNF Package, the values of attributes in the VnfInstance that have corresponding attributes \n in the VNFD shall be kept in sync with the values in the VNFD.\nNOTE 2:\tETSI GS NFV-SOL 001 [14] specifies the structure and format of the VNFD based on TOSCA specifications. NOTE 3:\tVNF configurable properties are sometimes also referred to as configuration parameters applicable \n to a VNF. Some of these are set prior to instantiation and cannot be modified if the VNF is instantiated, \n some are set prior to instantiation (are part of initial configuration) and can be modified later, \n and others can be set only after instantiation. The applicability of certain configuration may \n depend on the VNF and the required operation of the VNF at a certain point in time.\nNOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes \n of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared in the VNFD with a defined \n initial value. The defined initial values can be declared in the VNFD, and/or, in case of \"metadata\", \n obtained from the \"CreateVnfRequest\" structure. Child attributes of \"vnfConfigurableProperties\", \n \"metadata\" and \"extensions\" that have no defined initial value shall not be created, in order to be \n consistent with the semantics of the JSON Merge Patch method (see IETF RFC 7396) that interprets null \n values as deletion request.\nNOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a \n multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same \n VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed \n multi-site VL instance (refer to clause 5.5.3.3).\nNOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity, they shall \n not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\nNOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing \n the trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\nNOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the \n VNF LCM operation explicitly indicates the scale level for the aspect.\nNOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n","type":"object","required":["id","vnfdId","vnfProvider","vnfProductName","vnfSoftwareVersion","vnfdVersion","instantiationState","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceName":{"description":"Name of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfInstanceDescription":{"description":"Human-readable description of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"Provider of the VNF and the VNFD. The value is copied from the VNFD.\n","type":"string"},"vnfProductName":{"description":"Name to identify the VNF Product. The value is copied from the VNFD.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vimConnectionInfo":{"description":"Information about VIM or CISM connections to be used for managing the resources for the VNF instance. The keys of the map, each of which identifies information about a particular VIM connection, are managed by the NFVO and referenced from other data structures via the \"vimConnectionId\" attribute. This attribute shall only be supported and present if - the resources of at least of the VNFCs are managed by a VIM and VNF-related resource management in direct mode is applicable. - the resources of at least of the VNFCs are managed by a CISM. This attribute can be modified with the PATCH method. If VIM connection information is provisioned to the VNFM by means outside the scope of the present document, the information in the \"vimConnectionInfo\" attribute provides necessary information for binding the VnfInstance representing the \"Individual VNF instance\" to the applicable VIM connection information used to perform resource management for the VNF instance. See also the definition of the \"VimConnectionInfo\" in clause 4.4.1.6.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"cirConnectionInfo":{"description":"Information about the CIR connection for managing OS container images for the VNF instance. Shall be present when all or part of the VNF is realized by a set of OS containers and shall be absent otherwise.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mciopRepositoryInfo":{"description":"Information about the MCIOP repository for the VNF instance. Shall be present when all or part of the VNF is realized by a set of OS containers and shall be absent otherwise. See note 1.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"certificateInfo":{"description":"This type provides input information related to certificate and certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateConfigurationInfo":{"description":"This type provides input information related to certificate management.\n","type":"object","required":["securityPolicy"],"properties":{"certificateBaseProfile":{"description":"Information for certificate profile.","type":"array","items":{"description":"NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\nThis type provides input information to override certificate base profile for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"description":"Issuer of certificates. See note.","type":"string"},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to the subject of the certificate.\nNOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of the certification target subject FQDN. Can be set empty when this certificate is used for encrypted communication using IP address. See note.\n","type":"string"},"organization":{"description":"Information of the certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of the certification target subject Country. See note.","type":"string"},"state":{"description":"Information of the certification target subject State. See note.","type":"string"},"locality":{"description":"Information of the certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of the certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"description":"Basic constraints of certificates. See note.","type":"string"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [14], clause 7.1.19.4). See note.\n","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}}},"securityPolicy":{"description":"Information for security policy to be satisfied for certificate.","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"number"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"number"}}}},"delegationSupportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"cmfInfo":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["id","endPoint","supportedProtocol"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"endPoint":{"description":"End point of CMF instance.","type":"object","properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocol":{"description":"Supported protocols by CMF instance.","type":"array","items":{"description":"Supported protocol by CMF instance.","type":"string","enum":["CMP","CMPv2","EST","SCEP"]}},"certificateChain":{"description":"Certificate chain that this CMF provides.","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"certificateContents":{"description":"Information for contents of issued certificates. The information contained in this attribute may be updated over time during the VNF LCM, e.g., certificate(s) renewal.\n","type":"array","items":{"description":"This type provides input information related to certificate content.\nNOTE: The CertificateDesc data type is defined in clause 7.1.19.2 of ETSI GS NFV IFA 011 [10].\n","type":"object","required":["id","certificateDescId","certificateType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"certificateType":{"description":"Type of this certificate.","type":"string","enum":["VNFCI_CERT","VNFOAM_CERT"]},"supportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"version":{"description":"A version.\n","type":"string"},"serialNumber":{"description":"Serial number of this certificate.","type":"integer"},"signatureAlgorithm":{"description":"Algorithm of this certificate's signature.","type":"string"},"issuer":{"description":"Issuer of this certificate.","type":"string"},"notBefore":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"notAfter":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"subject":{"description":"Subject of this certificate.","type":"string"},"publicKeyAlgorithm":{"description":"Algorithm of this certificate's public key.","type":"string"},"publicKey":{"description":"Public key of this certificate.","type":"string"},"certificateExtensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"instantiationState":{"description":"The instantiation state of the VNF. Permitted values: - NOT_INSTANTIATED: The VNF instance is terminated or not instantiated. - INSTANTIATED: The VNF instance is instantiated.\n","type":"string","enum":["NOT_INSTANTIATED","INSTANTIATED"]},"instantiatedVnfInfo":{"description":"Information specific to an instantiated VNF instance. This attribute shall be present if the instantiateState attribute value is INSTANTIATED.\n","type":"object","required":["flavourId","vnfState"],"properties":{"flavourId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfState":{"description":"STARTED: The VNF instance is up and running. STOPPED: The VNF instance has been shut down.\n","type":"string","enum":["STARTED","STOPPED"]},"vnfPowerState":{"description":"This type represents information about the power state of a VNF instance.\n","type":"object","required":["powerProfileId","name"],"properties":{"powerProfileId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Name of the power profile as provided in the VNFD.\n","type":"string"},"powerConsumptionInfo":{"description":"This type represents information about estimated power consumption of the resources associated with the power profile, as provided in the VNFD.\n","type":"object","required":["minPowerConsumption","maxPowerConsumption","averagePowerConsumption"],"properties":{"minPowerConsumption":{"description":"Minimum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"maxPowerConsumption":{"description":"Maximum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"averagePowerConsumption":{"description":"Average power consumption of this power profile. Unit is KW/h.\n","type":"integer"}}}}},"scaleStatus":{"description":"Scale status of the VNF, one entry per aspect. Represents for every scaling aspect how \"big\" the VNF has been scaled w.r.t. that aspect.\nThis attribute shall be present if the VNF supports scaling. See clause B.2 for an explanation of VNF scaling.\nFor an aspect that has not been deployed because the related deployableModule has not been selected, it indicates the scale level that has been requested in the instantiation or in a scaling operation, or, if none has been requested in any of them, the scale level applicable to the aspect based on the default instantiation level. See note 8.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"maxScaleLevels":{"description":"Maximum allowed scale levels of the VNF, one entry per aspect. This attribute shall be present if the VNF supports scaling.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"selectedDeployableModule":{"description":"References a currently selected deployable module, as defined in the VNFD, that has already completed the instantiation of its VNFCs.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceCapacityDefinition":{"description":"Shows current values of VDU attributes related to resource capacity, if different to the default values from the VNFD, as indicated in the (one or more) request(s) of all completed VNF LCM operation(s) that contain this attribute. If an attribute value has been modified multiple times, only the last value is shown. The values indicated in this attribute are applicable to all VNFC instances based on the VDU to which the resourceCapacityDefinition is related.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes.\nThe tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request.\nAt most one tag can be included when the data type is used in a VNF LCM operation request.\nWhen the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.\n","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced.\n","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute 'type' indicates OSCONTAINER and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource. See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resource property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for this virtual compute descriptor. The value is a numberthat indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) that indicates the valid vaues for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"extCpInfo":{"description":"Information about the external CPs exposed by the VNF instance. When trunking is enabled, the list of entries includes both, external CPs corresponding to parent ports of a trunk, and external CPs associated to sub-ports of a trunk.See note 7.\n","type":"array","items":{"description":"This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n","type":"object","required":["id","cpdId","cpConfigId","cpProtocolInfo"],"oneOf":[{"required":["associatedVnfcCpId"]},{"required":["associatedVipCpId"]},{"required":["associatedVnfVirtualLinkId"]}],"properties":{"id":{"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"},"cpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extLinkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"associatedVnfcCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVipCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVirtualCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVnfVirtualLinkId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 3 and 4.\nIt shall be present if the external CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNF CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpSecurityGroupInfo":{"description":"This type provides the list of active security group rules applied to an external CP instance. The type identifies which \"SecurityGroupRule\" specified in the VNFD are activated and the values of its attributes.\n","type":"object","required":["securityGroupRuleId","etherType","protocol","portRangeMin","portRangeMax"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"description":{"description":"Human readable description of the security group rule.\n","type":"string"},"etherType":{"description":"Indicates the protocol carried over the Ethernet layer. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"protocol":{"description":"Indicates the protocol carried over the IP layer. Permitted values: any protocol defined in the IANA protocol registry (refer to clause 9.10.1.2 ofd ETSI GS NFV-SOL 001 for further information).\n","type":"string"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule.\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule.\n","type":"integer"}}}}}},"vipCpInfo":{"description":"VIP CPs that are part of the VNF instance. Shall be present when that particular VIP CP of the VNFC instance is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","minItems":1,"items":{"description":"This type provides information related to virtual IP (VIP) CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["cpInstanceId","cpdId"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for layer 3. There may be one cpProtocolInfo for layer 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"associatedVnfcCpIds":{"description":"Identifiers of the VnfcCps that share the virtual IP address allocated to the VIP CP instance. See note.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualCpInfo":{"description":"Virtual CPs that are part of the VNF instance. Shall be present when a particular Virtual CP is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","items":{"description":"This type provides information related to a virtual CP instance of a VNF.\nNOTE 1: A consumer of the VNF LCM interface can learn the actual VNFC instances implementing the service accessible via the virtual CP instance by querying the \"vnfcResourceInfo\" from the \"InstantiatedVnfInfo\" \n and filtering by corresponding \"vduIds\" values.\nNOTE 2: The information can be omitted because it is already available as part of the external CP information in the VnfExtCpInfo structure.\n","type":"object","required":["cpInstanceId","cpdId","resourceHandle","vduIds"],"properties":{"cpInstanceId":{"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"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for each layer protocol supported. This attribute may be omitted if the virtual CP is exposed as an external CP. See note 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vduIds":{"description":"Reference to the VDU(s) which implement the service accessible via the virtual CP instance. See note 1.\n","type":"array","minItems":1,"items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"additionalServiceInfo":{"description":"Additional service identification information of the virtual CP instance.\n","type":"array","items":{"description":"This type provides additional service information of the virtual CP instance used to expose properties of the virtual CP to NFV-MANO.\nNOTE: This attribute shall only be present if additional information is needed to identify the service termination within the VNF, such as for example a URL path information in an HTTP request required \n to allow a single virtual CP IP address to be used for several HTTP based services that use the \n same port number.\n","type":"object","required":["portInfo"],"properties":{"portInfo":{"description":"Service port numbers exposed by the virtual CP instance.\n","minItems":1,"type":"array","items":{"description":"This type describes the service identifying port properties exposed by the virtual CP instance.\n","type":"object","required":["name","port","portConfigurable"],"properties":{"name":{"description":"The name of the port exposed by the virtual CP instance.\n","type":"string"},"protocol":{"description":"The L4 protocol for this port exposed by the virtual CP instance.\nPermitted values: - TCP - UDP - SCTP\n","type":"string","enum":["TCP","UDP","SCTP"]},"port":{"description":"The L4 port number exposed by the virtual CP instance.\n","type":"integer"},"portConfigurable":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"}}}},"serviceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"extVirtualLinkInfo":{"description":"Information about the external VLs the VNF instance is connected to.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extManagedVirtualLinkInfo":{"description":"Information about the externally-managed internal VLs of the VNF instance. See notes 5 and 6.\n","type":"array","items":{"description":"This type provides information about an externally-managed virtual link. Note: Both \"vnfLinkPort\" and \"vnfNetAttDefResource\" attributes can be present in an \"ExtManagedVirtualLinkInfo\" to indicate that a single internal virtual link is providing connectivity for both VM-based and container-based \n VNFCs.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPorts":{"description":"Link ports of this VL. See note.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"vnfNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL. See note.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"extManagedMultisiteVirtualLinkId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"routingResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"monitoringParameters":{"description":"Active monitoring parameters.\n","type":"array","items":{"description":"This type represents a monitoring parameter that is tracked by the VNFM,\n","type":"object","required":["id","performanceMetric"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human readable name of the monitoring parameter, as defined in the VNFD.\n","type":"string"},"performanceMetric":{"description":"Performance metric that is monitored. This attribute shall contain the related \"Measurement Name\" value as defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"}}}},"localizationLanguage":{"description":"Information about localization language of the VNF (includes e.g. strings in the VNFD). The localization languages supported by a VNF can be declared in the VNFD, and localization language selection can take place at instantiation time. The value shall comply with the format defined in IETF RFC 5646.\n","type":"string"},"vnfcResourceInfo":{"description":"Information about the virtualised compute and storage resources used by the VNFCs of the VNF instance.\n","type":"array","items":{"description":"This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure of\n information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n a) For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n b) For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\nNOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on \n TOSCA specifications.\nNOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an \n internal VL that exposes an external CP. A VNFC CP is \"exposed as\" an external \n CP if it is connected directly to an external VL.\nNOTE 3:\tThe information can be omitted because it is already available as part of the \n external CP information.\nNOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\"\n structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVnfc\" structure in the VNF LCM operation occurrence notifications\n or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\nNOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment\n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. \nNOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n","type":"object","required":["id","vduId","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResourceIds":{"description":"References to the VirtualStorage resources or references to Storage MCIOs. The value refers to a VirtualStorageResourceInfo item in the VnfInstance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcCpInfo":{"description":"CPs of the VNFC instance. Shall be present when that particular CP of the VNFC instance is exposed as an external CP of the VNF instance or is connected to an external CP of the VNF instance. See note 2. May be present otherwise. See note 7.\n","type":"array","items":{"type":"object","required":["id","cpdId"],"properties":{"id":{"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"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP. May be omitted if the VNFC CP is exposed as an external CP. See note 3.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"parentCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 5 and 6. It shall be present if the internal CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfVirtualLinkResourceInfo":{"description":"Information about the virtualised network resources used by the VLs of the VNF instance. See note 6.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by an internal VL instance in a VNF instance.\nNote: If only the value or the presence of this attribute is changed in the \"VnfVirtualLinkResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including\n a related \"AffectedVirtualLink\" structure in the VNF LCM operation occurrence notifications or the\n \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLinkPorts":{"description":"Links ports of this VL. Shall be present when the linkPort is used for external connectivity by the VNF (refer to VnfLinkPortInfo). May be present otherwise.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualStorageResourceInfo":{"description":"Information on the virtualised storage resource(s) used as storage for the VNF instance.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance.\nNote: If only the value or the presence of this attribute is changed in the \"VirtualStorageResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVirtualStorage\" structure in the VNF LCM operation occurrence\n notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","virtualStorageDescId","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mcioInfo":{"description":"Information on the MCIO(s) representing VNFC instance(s) realized by one or a set of OS containers and created from the same VDU for the VNF instance.\n","type":"array","items":{"description":"This type provides information about an MCIO representing the set of VNFC instances realized by one or a set of OS containers which have been created based on the same VDU. Within the CISM, an MCIO controller monitors the actual state of an MCIO representing the set of VNFC instances realized by one or a set of OS containers and compare it to the desired state For an MCIO related to a VDU that has the attribute isNumOfInstancesClusterBased set to FALSE the desired state is specified in the respective declarative descriptor. For an MCIO related to a VDU that has the attribute isNumOfInstancesClusterBased set to TRUE, the desired state is determined by the number of CIS-nodes in the cluster that fulfil the VDU requirements.as specified in the respective declarative descriptor. It triggers actions toward the CIS to align the actual to the desired state. Monitoring the actual state includes monitoring the number of MCIO instances available at any specific point in time. In addition, an MCIO controller maintains properties and runtime information on the MCIO instances which have been created based on the same VDU. The McioInfo data structure provides the runtime information on the MCIOs obtained from the MCIO controller.\nNOTE: There are different types of MCIOs. The set of VNFC instances based on the same VDU is represented by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type \n of MCIO, e.g. a POD.\n\nRuntime information of the set of OS containers realizing an individual VNFC instance is not part of the McioInfo data structure; such runtime information is provided in the ResourceHandle data structure referenced from the VnfcResourceInfo. The McioInfo does not provide runtime information of a constituent VNFC instance created based on a specific VDU.\nNOTE 1: The type of MCIO as specified in the declarative descriptor of the MCIO, and that can be read from the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the \n “kind” property of the declarative descriptor.\nNOTE 2: If the attribute additionalInfo is present, it may contain runtime information on the actual and desired state of the MCIO(s). \nNOTE 3: When the container infrastructure service is a Kubernetes® instance, the mcioId is the combined values from the kind and name fields of the Kubernetes resource object, separated by a slash. \n Example: \"Deployment/abcd\". \nNOTE 4: When the container infrastructure service is a Kubernetes® instance, the mcioName is the name field of the resource object.\n","type":"object","required":["mcioId","mcioName","mcioNamespace","vduId","cismId","mcioType","desiredInstances","availableInstances"],"properties":{"mcioId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioName":{"description":"Human readable name of this MCIO. See note 4.\n","type":"string"},"mcioNamespace":{"description":"Namespace of this MCIO.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cismId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioType":{"description":"The type of MCIO. Specific values, their semantics and associated MCIO types are defined in clause 5.5.4.9. Additional values are also permitted. See note 1.\n","type":"string","enum":["Deployment","Statefulset","DaemonSet"]},"desiredInstances":{"description":"Number of desired MCIO instances.\n","type":"integer"},"availableInstances":{"description":"Number of available MCIO instances.\n","type":"integer"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this MCIO instance uses. Shall be present when using in delegation mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfPaasServiceInfo":{"description":"Information on the PaaS Services assigned and used by the VNF instance.\n","type":"array","items":{"description":"This type provides input information about a PaaS Service that is used by a VNF instance. The PaasServiceInfo is comprised of various sets of information. Some information comes from the VNFD, other information comes from the PaaS Service assets provided by the NFVO to the VNFM, and other information is provided at runtime information about the usage of the PaaS Service.\n","type":"object","required":["id","paasServiceId","paasServiceType","paasServiceRequestId","paasServiceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceType":{"description":"The type of PaaS Service. The value of this attribute is expected to be matched against values of the registered PaaS Services in the PSR.","type":"string"},"paasServiceVersion":{"description":"A version.\n","type":"string"},"paasServiceRequestId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"paasServiceHandle":{"description":"This type provides information enabling the access and use of the PaaS Service by the VNF instance. The type and format of the handle depends on the form that the PaaS Service is formed.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"indicators":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"instantiate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"terminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"heal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"operate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"createSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"revertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeCurrentVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"recentVnfLcmOperationLinks":{"description":"Links to the most recent LCM operation occurrences related to this resource. See note 9.\n","type":"object","properties":{"recentVnfLcmOperation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmInstantiation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmTerminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmHeal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmOperate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmModifyInfo":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmCreateSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmRevertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmSelectDplMods":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualVnfInstance.Patch.202":{"description":"202 ACCEPTED\n\nShall be returned when the request has been accepted for processing.\nOn success, the HTTP response shall include a \"Location\" HTTP header that\ncontains the URI of the newly-created \"Individual VNF LCM operation occurrence\"\nresource corresponding to the operation.\nThe response body shall be empty.\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualVnfInstance.Patch.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the \"Individual VNF\ninstance\" resource.\nTypically, this is due to the fact that another LCM\noperation is ongoing.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute should\nconvey more information about the error\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualVnfInstance.Patch.412":{"description":"412 Precondition Failed\n\nShall be returned upon the following error: A\nprecondition given in an HTTP request header is\nnot fulfilled.\nTypically, this is due to an ETag mismatch,\nindicating that the resource was modified by\nanother entity.\nThe response body should contain a\nProblemDetails structure, in which the \"detail\"\nattribute should convey more information about the\nerror.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualVnfInstance.Delete.204":{"description":"204 NO CONTENT\n\nShall be returned when the \"Individual VNF instance\" resource and the associated\nVNF identifier were deleted successfully.\nThe response body shall be empty.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualVnfInstance.Delete.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the \"Individual\nVNF instance\" resource is in INSTANTIATED state.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"InstantiateVnfInstance.Post.202":{"description":"202 ACCEPTED\n\nShall be returned when the request has been accepted for processing\nThe response body shall be empty.\nThe HTTP response shall include a \"Location\" HTTP header that\ncontains the URI of the newly-created \"Individual VNF LCM operation\noccurrence\" resource corresponding to the operation.\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"InstantiateVnfInstance.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the \"Individual\nVNF instance\" resource is in INSTANTIATED state,\nor that a required (see note) child attribute of the\n\"extensions\" attribute has not been set.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"ScaleVnfInstance.Post.202":{"description":"202 ACCEPTED\n\nShall be returned when the request has been accepted for processing.\nThe response body shall be empty.\nThe HTTP response shall include a \"Location\" HTTP header that\ncontains the URI of the newly-created \"VNF LCM operation\noccurrence\" resource corresponding to the operation.\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"Selectdeployablemodules.Post.202":{"description":"202 ACCEPTED\n\nShall be returned when the request has been accepted for processing.\nThe response body shall be empty.\nThe HTTP response shall include a \"Location\" HTTP header that contains the URI of the newly-created\n\"Individual VNF LCM operation occurrence\" resource corresponding to the operation.\n","headers":{"Location":{"description":"The resource URI of the created \"Individual VNF LCM operation\noccurrence\" resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided\nauthorization, or error details if the corresponding HTTP request\nhas provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"ScaleVnfInstance.Post.404":{"description":"404 NOT FOUND\n\nShall be returned upon the following error: The API\nproducer did not find a current representation for the\ntarget resource or is not willing to disclose that one\nexists.\nThe general cause for this error and its handling is\nspecified in clause 6.4 of ETSI GS NFV-SOL 013 [8],\nincluding rules for the presence of the response body.\nSpecifically in case of this task resource, the\nresponse code 404 shall also be returned if the task\nis not supported for the VNF instance represented by\nthe parent resource, which means that the task\nresource consequently does not exist.\nIn this case, the response body shall be present, and\nshall contain a ProblemDetails structure, in which the\n\"detail\" attribute shall convey more information about\nthe error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"ScaleVnfInstance.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the \"Individual\nVNF instance\" resource is in NOT_INSTANTIATED\nstate, that another lifecycle management operation is\nongoing, or that a required (see note) child attribute\nof the \"extensions\" attribute has not been set.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"ScaleToLevelVnfInstance.Post.202":{"description":"202 ACCEPTED\n\nShall be returned when the request has been accepted for processing.\nThe response body shall be empty.\nThe HTTP response shall include a \"Location\" HTTP header that\ncontains the URI of the newly-created \"VNF LCM operation\noccurrence\" resource corresponding to the operation.\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"ScaleToLevelVnfInstance.Post.404":{"description":"404 NOT FOUND\n\nShall be returned upon the following error: The API\nproducer did not find a current representation for the\ntarget resource or is not willing to disclose that one\nexists.\nThe general cause for this error and its handling is\nspecified in clause 6.4 of ETSI\nGS NFV-SOL 013 [8], including rules for the\npresence of the response body.\nSpecifically in case of this task resource, the\nresponse code 404 shall also be returned if the task\nis not supported for the VNF instance represented\nby the parent resource, which means that the task\nresource consequently does not exist.\nIn this case, the response body shall be present,\nand shall contain a ProblemDetails structure, in\nwhich the \"detail\" attribute shall convey more\ninformation about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"ScaleToLevelVnfInstance.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the VNF\ninstance resource is in NOT_INSTANTIATED state,\nthat another lifecycle management operation is\nongoing, or that a required (see note) child attribute\nof the \"extensions\" attribute has not been set.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"ChangeFlavourVnfInstance.Post.202":{"description":"202 ACCEPTED\n\nShall be returned when the request has been accepted for processing.\nThe response body shall be empty.\nThe HTTP response shall include a \"Location\" HTTP header that\ncontains the URI of the newly-created \"VNF LCM operation\noccurrence\" resource corresponding to the operation.\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"ChangeFlavourVnfInstance.Post.404":{"description":"404 NOT FOUND\n\nShall be returned upon the following error: The API\nproducer did not find a current representation for the\ntarget resource or is not willing to disclose that one\nexists.\nThe general cause for this error and its handling is\nspecified in clause 6.4 of ETSI\nGS NFV-SOL 013 [8], including rules for the\npresence of the response body.\nSpecifically in case of this task resource, the\nresponse code 404 shall also be returned if the task\nis not supported for the VNF instance represented\nby the parent resource, which means that the task\nresource consequently does not exist.\nIn this case, the response body shall be present,\nand shall contain a ProblemDetails structure, in\nwhich the \"detail\" attribute shall convey more\ninformation about the error\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"ChangeFlavourVnfInstance.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the \"Individual\nVNF instance\" resource is in NOT_INSTANTIATED\nstate, that another lifecycle management operation\nis ongoing, or that a required (see note) child\nattribute of the \"extensions\" attribute has not been\nset.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"TerminateVnfInstance.Post.202":{"description":"202 ACCEPTED\n\nShall be returned when the request has been accepted for processing.\nThe response body shall be empty.\nThe HTTP response shall include a \"Location\" HTTP header that\ncontains the URI of the newly-created \"VNF LCM operation\noccurrence\" resource corresponding to the operation.\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"TerminateVnfInstance.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the \"Individual\nVNF instance\" resource is in NOT_INSTANTIATED\nstate, that another lifecycle management operation is\nongoing, or that a required (see note) child attribute\nof the \"extensions\" attribute has not been set.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"HealVnfInstance.Post.202":{"description":"202 ACCEPTED\n\nShall be returned when the request has been accepted for processing.\nThe response body shall be empty.\nThe HTTP response shall include a \"Location\" HTTP header that\ncontains the URI of the newly-created \"VNF LCM operation\noccurrence\" resource corresponding to the operation.\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"HealVnfInstance.Post.404":{"description":"404 NOT FOUND\n\nShall be returned upon the following error: The API\nproducer did not find a current representation for the\ntarget resource or is not willing to disclose that one\nexists.\nThe general cause for this error and its handling is\nspecified in clause 6.4 of ETSI GS NFV-SOL 013 [8],\nincluding rules for the presence of the response body.\nSpecifically in case of this task resource, the\nresponse code 404 shall also be returned if the task\nis not supported for the VNF instance represented by\nthe parent resource, which means that the task\nresource consequently does not exist.\nIn this case, the response body shall be present, and\nshall contain a ProblemDetails structure, in which the\n\"detail\" attribute shall convey more information about\nthe error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"HealVnfInstance.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the \"Individual\nVNF instance\" resource is in NOT_INSTANTIATED\nstate, that another lifecycle management operation is\nongoing, or that a required (see note) child attribute\nof the \"extensions\" attribute has not been set.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"OperateVnfInstance.Post.202":{"description":"202 ACCEPTED\n\nShall be returned when the request has been accepted for processing.\nThe response body shall be empty.\nThe HTTP response shall include a \"Location\" HTTP header that\ncontains the URI of the newly-created \"VNF LCM operation\noccurrence\" resource corresponding to the operation.\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"OperateVnfInstance.Post.404":{"description":"404 NOT FOUND\n\nShall be returned upon the following error: The API\nproducer did not find a current representation for\nthe target resource or is not willing to disclose that\none exists.\nThe general cause for this error and its handling is\nspecified in clause 6.4 of ETSI\nGS NFV-SOL 013 [8], including rules for the\npresence of the response body.\nSpecifically in case of this task resource, the\nresponse code 404 shall also be returned if the\ntask is not supported for the VNF instance\nrepresented by the parent resource, which means\nthat the task resource consequently does not exist.\nIn this case, the response body shall be present,\nand shall contain a ProblemDetails structure, in\nwhich the \"detail\" attribute shall convey more\ninformation about the error\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"OperateVnfInstance.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the VNF\ninstance resource is in NOT_INSTANTIATED\nstate, that another lifecycle management operation\nis ongoing, or that a required (see note) child\nattribute of the \"extensions\" attribute has not been\nset.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"ChangeExtConnVnfInstance.Post.202":{"description":"202 ACCEPTED\n\nShall be returned when the request has been accepted for processing.\nThe response body shall be empty.\nThe HTTP response shall include a \"Location\" HTTP header that\ncontains the URI of the newly-created \"VNF LCM operation\noccurrence\" resource corresponding to the operation.\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"ChangeExtConnVnfInstance.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error:\nThe operation cannot be executed\ncurrently, due to a conflict with the state of\nthe resource.\nTypically, this is due to the fact that\nanother lifecycle management operation is\nongoing, or that a required (see note) child\nattribute of the \"extensions\" attribute has\nnot been set.\nThe response body shall contain a\nProblemDetails structure, in which the\n\"detail\" attribute shall convey more\ninformation about the error\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"ChangeVnfpkgVnfInstance.Post.202":{"description":"202 ACCEPTED\n\nShall be returned when the request has been accepted for processing.\nThe response body shall be empty.\nThe HTTP response shall include a \"Location\" HTTP header that contains the URI of\nthe newly-created \"VNF LCM operation occurrence\" resource corresponding to the operation.\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"ChangeVnfpkgVnfInstance.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error:\nThe operation cannot be executed\ncurrently, due to a conflict with the state of\nthe resource.\nTypically, this is due to the fact that\nanother lifecycle management operation is\nongoing.\nThe response body shall contain a\nProblemDetails structure, in which the\n\"detail\" attribute shall convey more\ninformation about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"VnfLcmOpOccs.Get.200":{"description":"200 OK\n\nShall be returned when status information for zero or more VNF lifecycle management\noperation occurrences has been queried successfully.\nThe response body shall contain in an array the status information about zero or more\nVNF lifecycle operation occurrences, as defined in clause 5.5.2.13.\nIf the \"filter\" URI parameter or one of the \"all_fields\", \"fields\" (if supported),\n\"exclude_fields\" (if supported) or \"exclude_default\" URI parameters was supplied in the request,\nthe data in the response body shall have been transformed according to the rules specified\nin clauses 5.2.2 and 5.3.2 of ETSI GS NFV-SOL 013, respectively.\nIf the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013\nfor this resource, inclusion of the Link HTTP header in this response shall follow the provisions\nin clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a VNF lifecycle management operation occurrence.\nNOTE 1:\tThis allows the NFVO to obtain the information contained in the latest \n \"result\" notification if it has not received it due to an error or a \n wrongly configured subscription filter.\nNOTE 2:\tNot more than one of changedInfo and modificationsTriggeredByVnfPkgChange \n shall be present.\nNOTE 3:\tFor a particular affected VL, there shall be as many \"AffectedVirtualLink\" \n entries as needed for signalling the different types of changes, i.e. one \n per virtual link and change type. For instance, in the case of signaling \n affected VL instances involving the addition of a particular VL instance \n with links ports, one \"AffectedVirtualLink\" entry signals the addition of \n the VL by using the \"changeType\" attribute of \"AffectedVirtualLink\" structure \n equal to \"ADDED\", and another \"AffectedVirtualLink\" entry signals the addition \n of externally visible VNF link ports of the VL by using the \"changeType\" equal \n to \"LINK_PORT_ADDED\".\nNOTE 4:\tA coordination action has timed out if the VNFM has not been able to read the \n \"Individual coordination action\" resource within a timeout interval after requesting \n the coordination to be started or to be cancelled. The length of the timeout interval \n is defined by means outside the scope of the present document.\nNOTE 5: The list of rejected coordinations may be garbage collected if the LCM operation\n occurrence has reached a terminal state, i.e. one of \"COMPLETED\", \"FAILED\" and \"ROLLED_BACK\".\n","type":"object","oneOf":[{"required":["changedInfo"]},{"required":["modificationsTriggeredByVnfPkgChange"]}],"required":["id","operationState","stateEnteredTime","startTime","vnfInstanceId","operation","isAutomaticInvocation","isCancelPending"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"operationState":{"description":"STARTING: The LCM operation is starting. PROCESSING: The LCM operation is currently in execution. COMPLETED: The LCM operation has been completed successfully. FAILED_TEMP: The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED: The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK: The LCM operation is currently being rolled back. ROLLED_BACK: The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible.\n","type":"string","enum":["STARTING","PROCESSING","COMPLETED","FAILED_TEMP","FAILED","ROLLING_BACK","ROLLED_BACK"]},"stateEnteredTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"startTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"grantId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"operation":{"description":"The enumeration LcmOpType defines the permitted values to represent VNF lifecycle operation types in VNF lifecycle management operation occurrence resources and VNF lifecycle management operation occurrence notifications.\nValue | Description ------|------------ INSTANTIATE | Represents the \"Instantiate VNF\" LCM operation. SCALE | Represents the \"Scale VNF\" LCM operation. SCALE_TO_LEVEL | Represents the \"Scale VNF to Level\" LCM operation. CHANGE_FLAVOUR | Represents the \"Change VNF Flavour\" LCM operation. TERMINATE | Represents the \"Terminate VNF\" LCM operation. HEAL | Represents the \"Heal VNF\" LCM operation. OPERATE | Represents the \"Operate VNF\" LCM operation. CHANGE_EXT_CONN | Represents the \"Change external VNF connectivity\" LCM operation. MODIFY_INFO | Represents the \"Modify VNF Information\" LCM operation. CREATE_SNAPSHOT | Represents the \"Create VNF Snapshot\" LCM operation. REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot\" LCM operation. CHANGE_VNFPKG | Represents the \"Change current VNF package\" LCM operation. SELECT_DEPL_MODS | Represents the “Select VNF deployable modules” LCM operation\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","MODIFY_INFO","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","CHANGE_VNFPKG","SELECT_DEPL_MODS"]},"isAutomaticInvocation":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"operationParams":{"description":"Input parameters of the LCM operation. This attribute shall be formatted according to the request data type of the related LCM operation. In addition, the provisions in clause 5.7 shall apply.\nThe following mapping between operationType and the data type of this attribute shall apply: * INSTANTIATE: InstantiateVnfRequest * SCALE: ScaleVnfRequest * SCALE_TO_LEVEL: ScaleVnfToLevelRequest * CHANGE_FLAVOUR: ChangeVnfFlavourRequest * OPERATE: OperateVnfRequest * HEAL: HealVnfRequest * CHANGE_EXT_CONN: ChangeExtVnfConnectivityRequest * TERMINATE: TerminateVnfRequest * MODIFY_INFO: VnfInfoModifications * CREATE_SNAPSHOT: CreateVnfSnapshotRequest * REVERT_TO_SNAPSHOT: RevertToVnfSnapshotRequest * CHANGE_VNFPKG: ChangeCurrentVnfPkgRequest * SELECT_DEPL_MODS: SelectVnfDeployableModulesRequest\n","type":"object"},"isCancelPending":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"cancelMode":{"description":"Cancellation mode. GRACEFUL: If the VNF LCM operation occurrence is in \"PROCESSING\" or \"ROLLING_BACK\" state, the VNFM shall not start any new resource management operation and shall wait for the ongoing resource management operations in the underlying system, typically the VIM, to finish execution or to time out. After that, the VNFM shall put the operation occurrence into the FAILED_TEMP state. If the VNF LCM operation occurrence is in \"STARTING\" state, the VNFM shall not start any resource management operation and shall wait for the granting request to finish execution or time out. After that, the VNFM shall put the operation occurrence into the ROLLED_BACK state. FORCEFUL: If the VNF LCM operation occurrence is in \"PROCESSING\" or \"ROLLING_BACK\" state, the VNFM shall not start any new resource management operation, shall cancel the ongoing resource management operations in the underlying system, typically the VIM, and shall wait for the cancellation to finish or to time out. After that, the VNFM shall put the operation occurrence into the FAILED_TEMP state. If the VNF LCM operation occurrence is in \"STARTING\" state, the VNFM shall not start any resource management operation and put the operation occurrence into the ROLLED_BACK state.\n","type":"string","enum":["GRACEFUL","FORCEFUL"]},"error":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}},"resourceChanges":{"description":"This attribute contains information about the cumulative changes to virtualised resources that were performed so far by the LCM operation since its start, if applicable.\n","type":"object","properties":{"affectedVnfcs":{"description":"Information about VNFC instances that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary VNFCs.\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer \n (i.e. the NFVO) to assist in correlating the resource changes performed during \n the LCM operation with the granted resources in a specific Grant exchange, which \n is identified by the \"grantId\" available in the \"Individual VNF lifecycle management \n operation occurrence\" and the \"id\" in the \"Individual Grant\".\n","type":"object","required":["id","vduId","changeType","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY For a temporary resource, an AffectedVnfc structure exists as long as the temporary resource exists.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY"]},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"affectedVnfcCpIds":{"description":"Identifiers of CP(s) of the VNFC instance that were affected by the change. Shall be present for those affected CPs of the VNFC instance that are associated to an external CP of the VNF instance. May be present for further affected CPs of the VNFC instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"addedStorageResourceIds":{"description":"References to VirtualStorage resources that have been added. Each value refers to a VirtualStorageResourceInfo item in the VnfInstance that was added to the VNFC. It shall be provided if at least one storage resource was added to the VNFC.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"removedStorageResourceIds":{"description":"References to VirtualStorage resources that have been removed. The value contains the identifier of a VirtualStorageResourceInfo item that has been removed from the VNFC, and might no longer exist in the VnfInstance. It shall be provided if at least one storage resource was removed from the VNFC.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"affectedVirtualLinks":{"description":"Information about VL instances that were affected during the lifecycle operation. See notes 1 and 3.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary VLs, and added or removed VNF link ports.\nNOTE 1:\tWhen signalling the addition (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) of VNF link ports, \n the \"networkResource\" and \"resourceDefinitionId\" attributes refer to the affected virtual link \n instance, not the link port instance. The resource handles of the affected VNF link ports can be \n found by dereferencing the identifiers in the \"vnfLinkPortIds\" attribute.\nNOTE 2:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to \n assist in correlating the resource changes performed during the LCM operation with the granted \n resources in a specific Grant exchange, which is identified by the \"grantId\" available in the \n \"Individual VNF lifecycle management operation occurrence\" and the \"id\" in the \"Individual Grant\".\n","type":"object","required":["id","vnfVirtualLinkDescId","changeType","networkResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change.\nPermitted values: -\tADDED -\tREMOVED -\tMODIFIED -\tTEMPORARY -\tLINK_PORT_ADDED -\tLINK_PORT_REMOVED For a temporary resource, an AffectedVirtualLink structure exists as long as the temporary resource exists. See note 1.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY","LINK_PORT_ADDED","LINK_PORT_REMOVED"]},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPortIds":{"description":"Identifiers of the link ports of the affected VL related to the change. Each identifier references a \"VnfLinkPortInfo\" structure.\nShall be set when changeType is equal to \"LINK_PORT_ADDED\" or \"LINK_PORT_REMOVED\", and the related \"VnfLinkPortInfo\" structures are present (case \"added\") or have been present (case \"removed\") in the \"VnfVirtualLinkResourceInfo\" or \"ExtManagedVirtualLinkInfo\" structures that are represented by the \"vnfVirtualLinkResource¬Info\" or \"extManagedVirtualLinkInfo\" attribute in the \"VnfInstance\" structure. See note 1.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"affectedExtLinkPorts":{"description":"Information about external VNF link ports that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added and deleted external link ports (link ports attached to external virtual links).\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to assist in correlating \n the resource changes performed during the LCM operation with the granted resources in a specific Grant exchange, which \n is identified by the \"grantId\" available in the \"Individual VNF lifecycle management operation occurrence\" and the \"id\" \n in the \"Individual Grant\".\n","type":"object","required":["id","changeType","extCpInstanceId","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: -\tADDED - MODIFIED -\tREMOVED\n","type":"string","enum":["ADDED","MODIFIED","REMOVED"]},"extCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"}}}},"affectedVirtualStorages":{"description":"Information about virtualised storage instances that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary virtual storage resources.\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to \n assist in correlating the resource changes performed during the LCM operation with the granted \n resources in a specific Grant exchange, which is identified by the \"grantId\" available in the \n \"Individual VNF lifecycle management operation occurrence\" and the \"id\" in the \"Individual Grant\".\n","type":"object","required":["id","virtualStorageDescId","changeType","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY For a temporary resource, an AffectedVirtualStorage structure exists as long as the temporary resource exists.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY"]},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"changedInfo":{"description":"This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource. The attributes that can be included consist of those requested to be modified explicitly in the \"VnfInfoModificationRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly e.g. when modifying the referenced VNF package.\nNOTE:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) \n was modified implicitly following a request to modify the \"vnfdId\" attribute, by \n copying the value of this attribute from the VNFD in the VNF Package identified by \n the \"vnfdId\" attribute.\n","type":"object","properties":{"vnfInstanceName":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfInstanceDescription":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vimConnectionInfo":{"description":"If present, this attribute signals modifications the \"vimConnectionInfo\" attribute array in \"VnfInstance\".\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfProductName":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"}}},"affectedVipCps":{"description":"Information about virtual IP CP instances that were affected during the execution of the lifecycle management operation.\n","type":"array","items":{"description":"This type provides information about added, deleted and modified virtual IP CP instances.\n","type":"object","required":["cpInstanceId","cpdId","changeType"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: -\tADDED -\tREMOVED -\tMODIFIED\n","type":"string","enum":["ADDED","REMOVED","MODIFIED"]}}}},"changedExtConnectivity":{"description":"Information about changed external connectivity, if applicable. See note 1.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"modificationsTriggeredByVnfPkgChange":{"description":"This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource when changing the current VNF package. The attributes that can be included consist of those requested to be modified explicitly in the \"ChangeCurrentVnfPkgRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly during the operation.\nNOTE 1:\tThis attribute represents the delta (semantics as per IETF RFC 7396, JSON Merge Patch) between the value \n of the attribute at the start of the \"Change current VNF package\" operation and the value of the attribute \n at its completion.\nNOTE 2:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) was modified implicitly \n during the related operation and contains a copy of the value of the related attribute from the VNFD in the \n VNF Package identified by the \"vnfdId\" attribute.\n","type":"object","properties":{"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"If present, this attribute signals the new value of the \"vnfProvider\" attribute in \"VnfInstance\". See note 2.\n","type":"string"},"vnfProductName":{"description":"If present, this attribute signals the new value of the \"vnfProductName\" attribute in \"VnfInstance\". See note 2.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vimConnectionInfo":{"description":"If present, this attribute signals the changes to VIM connection info that were passed in the related \"ChangeCurrentVnfPkgRequest\" structure.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"vnfSnapshotInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"lcmCoordinations":{"description":"Information about LCM coordination actions (see clause 10 in ETSI GS NFV-SOL002) related to this LCM operation occurrence.\n","type":"array","items":{"type":"object","required":["id","coordinationActionName","startTime","endpointType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"coordinationActionName":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"coordinationResult":{"description":"The enumeration LcmCoordResultType defines the permitted values to represent the result of executing an LCM coordination action. The coordination result also implies the action to be performed by the VNFM as the follow-up to this coordination. Value | Description ------|------------ CONTINUE | The related LCM operation shall be continued, staying in the state \"PROCESSING\". ABORT | The related LCM operation shall be aborted by transitioning into the state \"FAILED_TEMP\". CANCELLED | The coordination action has been cancelled upon request of the API consumer, i.e. the VNFM. The related LCM operation shall be aborted by transitioning into the state \"FAILED_TEMP\".\n","type":"string","enum":["CONTINUE","ABORT","CANCELLED"]},"startTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"endTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"delay":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"endpointType":{"description":"The endpoint type used by this coordination action. Valid values: •\tMGMT: coordination with other operation supporting management systems (e.g. EM) •\tVNF: coordination with the VNF instance\n","type":"string","enum":["MGMT","VNF"]}}}},"rejectedLcmCoordinations":{"description":"Information about LCM coordination actions (see clause 10 in ETSI GS NFV-SOL002) that were rejected by 503 error which means they can be tried again after a delay. See note 5.\n","type":"array","items":{"type":"object","required":["coordinationActionName","rejectionTime","endpointType","delay"],"properties":{"coordinationActionName":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"rejectionTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"delay":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"endpointType":{"description":"The endpoint type used by this coordination action. Valid values: •\tMGMT: coordination with other operation supporting management systems (e.g. EM) •\tVNF: coordination with the VNF instance\n","type":"string","enum":["MGMT","VNF"]}}}},"warnings":{"description":"Warning messages that were generated while the operation was executing.\nIf the operation has included LCM coordination actions and these have resulted in warnings, such warnings should be added to this attribute.\n","type":"array","items":{"type":"string"}},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self","vnfInstance"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"grant":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"cancel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"retry":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"rollback":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"fail":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"IndividualVnfLcmOpOcc.Get.200":{"description":"200 OK\n\nShall be returned when information about a VNF LCM operation occurrence washas been read successfully.\nThe response body shall contain status information about a VNF lifecycle management operation occurrence\n(see clause 5.5.2.13).\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a VNF lifecycle management operation occurrence.\nNOTE 1:\tThis allows the NFVO to obtain the information contained in the latest \n \"result\" notification if it has not received it due to an error or a \n wrongly configured subscription filter.\nNOTE 2:\tNot more than one of changedInfo and modificationsTriggeredByVnfPkgChange \n shall be present.\nNOTE 3:\tFor a particular affected VL, there shall be as many \"AffectedVirtualLink\" \n entries as needed for signalling the different types of changes, i.e. one \n per virtual link and change type. For instance, in the case of signaling \n affected VL instances involving the addition of a particular VL instance \n with links ports, one \"AffectedVirtualLink\" entry signals the addition of \n the VL by using the \"changeType\" attribute of \"AffectedVirtualLink\" structure \n equal to \"ADDED\", and another \"AffectedVirtualLink\" entry signals the addition \n of externally visible VNF link ports of the VL by using the \"changeType\" equal \n to \"LINK_PORT_ADDED\".\nNOTE 4:\tA coordination action has timed out if the VNFM has not been able to read the \n \"Individual coordination action\" resource within a timeout interval after requesting \n the coordination to be started or to be cancelled. The length of the timeout interval \n is defined by means outside the scope of the present document.\nNOTE 5: The list of rejected coordinations may be garbage collected if the LCM operation\n occurrence has reached a terminal state, i.e. one of \"COMPLETED\", \"FAILED\" and \"ROLLED_BACK\".\n","type":"object","oneOf":[{"required":["changedInfo"]},{"required":["modificationsTriggeredByVnfPkgChange"]}],"required":["id","operationState","stateEnteredTime","startTime","vnfInstanceId","operation","isAutomaticInvocation","isCancelPending"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"operationState":{"description":"STARTING: The LCM operation is starting. PROCESSING: The LCM operation is currently in execution. COMPLETED: The LCM operation has been completed successfully. FAILED_TEMP: The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED: The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK: The LCM operation is currently being rolled back. ROLLED_BACK: The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible.\n","type":"string","enum":["STARTING","PROCESSING","COMPLETED","FAILED_TEMP","FAILED","ROLLING_BACK","ROLLED_BACK"]},"stateEnteredTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"startTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"grantId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"operation":{"description":"The enumeration LcmOpType defines the permitted values to represent VNF lifecycle operation types in VNF lifecycle management operation occurrence resources and VNF lifecycle management operation occurrence notifications.\nValue | Description ------|------------ INSTANTIATE | Represents the \"Instantiate VNF\" LCM operation. SCALE | Represents the \"Scale VNF\" LCM operation. SCALE_TO_LEVEL | Represents the \"Scale VNF to Level\" LCM operation. CHANGE_FLAVOUR | Represents the \"Change VNF Flavour\" LCM operation. TERMINATE | Represents the \"Terminate VNF\" LCM operation. HEAL | Represents the \"Heal VNF\" LCM operation. OPERATE | Represents the \"Operate VNF\" LCM operation. CHANGE_EXT_CONN | Represents the \"Change external VNF connectivity\" LCM operation. MODIFY_INFO | Represents the \"Modify VNF Information\" LCM operation. CREATE_SNAPSHOT | Represents the \"Create VNF Snapshot\" LCM operation. REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot\" LCM operation. CHANGE_VNFPKG | Represents the \"Change current VNF package\" LCM operation. SELECT_DEPL_MODS | Represents the “Select VNF deployable modules” LCM operation\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","MODIFY_INFO","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","CHANGE_VNFPKG","SELECT_DEPL_MODS"]},"isAutomaticInvocation":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"operationParams":{"description":"Input parameters of the LCM operation. This attribute shall be formatted according to the request data type of the related LCM operation. In addition, the provisions in clause 5.7 shall apply.\nThe following mapping between operationType and the data type of this attribute shall apply: * INSTANTIATE: InstantiateVnfRequest * SCALE: ScaleVnfRequest * SCALE_TO_LEVEL: ScaleVnfToLevelRequest * CHANGE_FLAVOUR: ChangeVnfFlavourRequest * OPERATE: OperateVnfRequest * HEAL: HealVnfRequest * CHANGE_EXT_CONN: ChangeExtVnfConnectivityRequest * TERMINATE: TerminateVnfRequest * MODIFY_INFO: VnfInfoModifications * CREATE_SNAPSHOT: CreateVnfSnapshotRequest * REVERT_TO_SNAPSHOT: RevertToVnfSnapshotRequest * CHANGE_VNFPKG: ChangeCurrentVnfPkgRequest * SELECT_DEPL_MODS: SelectVnfDeployableModulesRequest\n","type":"object"},"isCancelPending":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"cancelMode":{"description":"Cancellation mode. GRACEFUL: If the VNF LCM operation occurrence is in \"PROCESSING\" or \"ROLLING_BACK\" state, the VNFM shall not start any new resource management operation and shall wait for the ongoing resource management operations in the underlying system, typically the VIM, to finish execution or to time out. After that, the VNFM shall put the operation occurrence into the FAILED_TEMP state. If the VNF LCM operation occurrence is in \"STARTING\" state, the VNFM shall not start any resource management operation and shall wait for the granting request to finish execution or time out. After that, the VNFM shall put the operation occurrence into the ROLLED_BACK state. FORCEFUL: If the VNF LCM operation occurrence is in \"PROCESSING\" or \"ROLLING_BACK\" state, the VNFM shall not start any new resource management operation, shall cancel the ongoing resource management operations in the underlying system, typically the VIM, and shall wait for the cancellation to finish or to time out. After that, the VNFM shall put the operation occurrence into the FAILED_TEMP state. If the VNF LCM operation occurrence is in \"STARTING\" state, the VNFM shall not start any resource management operation and put the operation occurrence into the ROLLED_BACK state.\n","type":"string","enum":["GRACEFUL","FORCEFUL"]},"error":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}},"resourceChanges":{"description":"This attribute contains information about the cumulative changes to virtualised resources that were performed so far by the LCM operation since its start, if applicable.\n","type":"object","properties":{"affectedVnfcs":{"description":"Information about VNFC instances that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary VNFCs.\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer \n (i.e. the NFVO) to assist in correlating the resource changes performed during \n the LCM operation with the granted resources in a specific Grant exchange, which \n is identified by the \"grantId\" available in the \"Individual VNF lifecycle management \n operation occurrence\" and the \"id\" in the \"Individual Grant\".\n","type":"object","required":["id","vduId","changeType","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY For a temporary resource, an AffectedVnfc structure exists as long as the temporary resource exists.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY"]},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"affectedVnfcCpIds":{"description":"Identifiers of CP(s) of the VNFC instance that were affected by the change. Shall be present for those affected CPs of the VNFC instance that are associated to an external CP of the VNF instance. May be present for further affected CPs of the VNFC instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"addedStorageResourceIds":{"description":"References to VirtualStorage resources that have been added. Each value refers to a VirtualStorageResourceInfo item in the VnfInstance that was added to the VNFC. It shall be provided if at least one storage resource was added to the VNFC.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"removedStorageResourceIds":{"description":"References to VirtualStorage resources that have been removed. The value contains the identifier of a VirtualStorageResourceInfo item that has been removed from the VNFC, and might no longer exist in the VnfInstance. It shall be provided if at least one storage resource was removed from the VNFC.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"affectedVirtualLinks":{"description":"Information about VL instances that were affected during the lifecycle operation. See notes 1 and 3.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary VLs, and added or removed VNF link ports.\nNOTE 1:\tWhen signalling the addition (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) of VNF link ports, \n the \"networkResource\" and \"resourceDefinitionId\" attributes refer to the affected virtual link \n instance, not the link port instance. The resource handles of the affected VNF link ports can be \n found by dereferencing the identifiers in the \"vnfLinkPortIds\" attribute.\nNOTE 2:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to \n assist in correlating the resource changes performed during the LCM operation with the granted \n resources in a specific Grant exchange, which is identified by the \"grantId\" available in the \n \"Individual VNF lifecycle management operation occurrence\" and the \"id\" in the \"Individual Grant\".\n","type":"object","required":["id","vnfVirtualLinkDescId","changeType","networkResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change.\nPermitted values: -\tADDED -\tREMOVED -\tMODIFIED -\tTEMPORARY -\tLINK_PORT_ADDED -\tLINK_PORT_REMOVED For a temporary resource, an AffectedVirtualLink structure exists as long as the temporary resource exists. See note 1.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY","LINK_PORT_ADDED","LINK_PORT_REMOVED"]},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPortIds":{"description":"Identifiers of the link ports of the affected VL related to the change. Each identifier references a \"VnfLinkPortInfo\" structure.\nShall be set when changeType is equal to \"LINK_PORT_ADDED\" or \"LINK_PORT_REMOVED\", and the related \"VnfLinkPortInfo\" structures are present (case \"added\") or have been present (case \"removed\") in the \"VnfVirtualLinkResourceInfo\" or \"ExtManagedVirtualLinkInfo\" structures that are represented by the \"vnfVirtualLinkResource¬Info\" or \"extManagedVirtualLinkInfo\" attribute in the \"VnfInstance\" structure. See note 1.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"affectedExtLinkPorts":{"description":"Information about external VNF link ports that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added and deleted external link ports (link ports attached to external virtual links).\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to assist in correlating \n the resource changes performed during the LCM operation with the granted resources in a specific Grant exchange, which \n is identified by the \"grantId\" available in the \"Individual VNF lifecycle management operation occurrence\" and the \"id\" \n in the \"Individual Grant\".\n","type":"object","required":["id","changeType","extCpInstanceId","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: -\tADDED - MODIFIED -\tREMOVED\n","type":"string","enum":["ADDED","MODIFIED","REMOVED"]},"extCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"}}}},"affectedVirtualStorages":{"description":"Information about virtualised storage instances that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary virtual storage resources.\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to \n assist in correlating the resource changes performed during the LCM operation with the granted \n resources in a specific Grant exchange, which is identified by the \"grantId\" available in the \n \"Individual VNF lifecycle management operation occurrence\" and the \"id\" in the \"Individual Grant\".\n","type":"object","required":["id","virtualStorageDescId","changeType","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY For a temporary resource, an AffectedVirtualStorage structure exists as long as the temporary resource exists.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY"]},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"changedInfo":{"description":"This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource. The attributes that can be included consist of those requested to be modified explicitly in the \"VnfInfoModificationRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly e.g. when modifying the referenced VNF package.\nNOTE:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) \n was modified implicitly following a request to modify the \"vnfdId\" attribute, by \n copying the value of this attribute from the VNFD in the VNF Package identified by \n the \"vnfdId\" attribute.\n","type":"object","properties":{"vnfInstanceName":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfInstanceDescription":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vimConnectionInfo":{"description":"If present, this attribute signals modifications the \"vimConnectionInfo\" attribute array in \"VnfInstance\".\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfProductName":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"}}},"affectedVipCps":{"description":"Information about virtual IP CP instances that were affected during the execution of the lifecycle management operation.\n","type":"array","items":{"description":"This type provides information about added, deleted and modified virtual IP CP instances.\n","type":"object","required":["cpInstanceId","cpdId","changeType"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: -\tADDED -\tREMOVED -\tMODIFIED\n","type":"string","enum":["ADDED","REMOVED","MODIFIED"]}}}},"changedExtConnectivity":{"description":"Information about changed external connectivity, if applicable. See note 1.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"modificationsTriggeredByVnfPkgChange":{"description":"This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource when changing the current VNF package. The attributes that can be included consist of those requested to be modified explicitly in the \"ChangeCurrentVnfPkgRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly during the operation.\nNOTE 1:\tThis attribute represents the delta (semantics as per IETF RFC 7396, JSON Merge Patch) between the value \n of the attribute at the start of the \"Change current VNF package\" operation and the value of the attribute \n at its completion.\nNOTE 2:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) was modified implicitly \n during the related operation and contains a copy of the value of the related attribute from the VNFD in the \n VNF Package identified by the \"vnfdId\" attribute.\n","type":"object","properties":{"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"If present, this attribute signals the new value of the \"vnfProvider\" attribute in \"VnfInstance\". See note 2.\n","type":"string"},"vnfProductName":{"description":"If present, this attribute signals the new value of the \"vnfProductName\" attribute in \"VnfInstance\". See note 2.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vimConnectionInfo":{"description":"If present, this attribute signals the changes to VIM connection info that were passed in the related \"ChangeCurrentVnfPkgRequest\" structure.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"vnfSnapshotInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"lcmCoordinations":{"description":"Information about LCM coordination actions (see clause 10 in ETSI GS NFV-SOL002) related to this LCM operation occurrence.\n","type":"array","items":{"type":"object","required":["id","coordinationActionName","startTime","endpointType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"coordinationActionName":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"coordinationResult":{"description":"The enumeration LcmCoordResultType defines the permitted values to represent the result of executing an LCM coordination action. The coordination result also implies the action to be performed by the VNFM as the follow-up to this coordination. Value | Description ------|------------ CONTINUE | The related LCM operation shall be continued, staying in the state \"PROCESSING\". ABORT | The related LCM operation shall be aborted by transitioning into the state \"FAILED_TEMP\". CANCELLED | The coordination action has been cancelled upon request of the API consumer, i.e. the VNFM. The related LCM operation shall be aborted by transitioning into the state \"FAILED_TEMP\".\n","type":"string","enum":["CONTINUE","ABORT","CANCELLED"]},"startTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"endTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"delay":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"endpointType":{"description":"The endpoint type used by this coordination action. Valid values: •\tMGMT: coordination with other operation supporting management systems (e.g. EM) •\tVNF: coordination with the VNF instance\n","type":"string","enum":["MGMT","VNF"]}}}},"rejectedLcmCoordinations":{"description":"Information about LCM coordination actions (see clause 10 in ETSI GS NFV-SOL002) that were rejected by 503 error which means they can be tried again after a delay. See note 5.\n","type":"array","items":{"type":"object","required":["coordinationActionName","rejectionTime","endpointType","delay"],"properties":{"coordinationActionName":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"rejectionTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"delay":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"endpointType":{"description":"The endpoint type used by this coordination action. Valid values: •\tMGMT: coordination with other operation supporting management systems (e.g. EM) •\tVNF: coordination with the VNF instance\n","type":"string","enum":["MGMT","VNF"]}}}},"warnings":{"description":"Warning messages that were generated while the operation was executing.\nIf the operation has included LCM coordination actions and these have resulted in warnings, such warnings should be added to this attribute.\n","type":"array","items":{"type":"string"}},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self","vnfInstance"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"grant":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"cancel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"retry":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"rollback":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"fail":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"RollbackVnfLcmOpOcc.Post.202":{"description":"202 ACCEPTED\n\nShall be returned when the request has been accepted for processing.\nThe response shall have an empty message content.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"RollbackVnfLcmOpOcc.Post.404":{"description":"404 NOT FOUND\n\nShall be returned upon the following error: The API\nproducer did not find a current representation for the\ntarget resource or is not willing to disclose that one\nexists.\nThe general cause for this error and its handling is\nspecified in clause 6.4 of ETSI GS NFV-SOL 013 [8],\nincluding rules for the presence of the response body.\nSpecifically in case of this task resource, the response\ncode 404 shall also be returned if the task is not\nsupported for the VNF LCM operation occurrence\nrepresented by the parent resource, which means that\nthe task resource consequently does not exist.\nIn this case, the response body shall be present, and\nshall contain a ProblemDetails structure, in which the\n\"detail\" attribute shall convey more information about\nthe error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"RollbackVnfLcmOpOcc.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the VNF LCM operation\noccurrence.\nTypically, this is due to the fact that the VNF LCM\noperation occurrence is not in FAILED_TEMP state, or\nanother error handling action is starting, such as retry\nor fail.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"RetryVnfLcmOpOcc.Post.202":{"description":"202 ACCEPTED\n\nShall be returned when the request has been accepted for processing.\nThe response shall have an empty message content.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"RetryVnfLcmOpOcc.Post.404":{"description":"404 NOT FOUND\n\nShall be returned upon the following error: The API\nproducer did not find a current representation for the\ntarget resource or is not willing to disclose that one\nexists.\nThe general cause for this error and its handling is\nspecified in clause 6.4 of ETSI GS NFV-SOL 013 [8],\nincluding rules for the presence of the response body.\nSpecifically in case of this task resource, the response\ncode 404 shall also be returned if the task is not\nsupported for the VNF LCM operation occurrence\nrepresented by the parent resource, which means that\nthe task resource consequently does not exist.\nIn this case, the response body shall be present, and\nshall contain a ProblemDetails structure, in which the\n\"detail\" attribute shall convey more information about\nthe error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"RetryVnfLcmOpOcc.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the VNF LCM operation\noccurrence.\nTypically, this is due to the fact that the VNF LCM\noperation occurrence is not in FAILED_TEMP state, or\nanother error handling action is starting, such as\nrollback or fail.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"FailVnfLcmOpOcc.Post.200":{"description":"200 OK\n\nShall be returned when the state of the VNF lifecycle management operation occurrence\nhas been changed successfully.\nThe response body shall include a representation of the \"Individual VNF lifecycle operation occurrence\"\nresource.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a VNF lifecycle management operation occurrence.\nNOTE 1:\tThis allows the NFVO to obtain the information contained in the latest \n \"result\" notification if it has not received it due to an error or a \n wrongly configured subscription filter.\nNOTE 2:\tNot more than one of changedInfo and modificationsTriggeredByVnfPkgChange \n shall be present.\nNOTE 3:\tFor a particular affected VL, there shall be as many \"AffectedVirtualLink\" \n entries as needed for signalling the different types of changes, i.e. one \n per virtual link and change type. For instance, in the case of signaling \n affected VL instances involving the addition of a particular VL instance \n with links ports, one \"AffectedVirtualLink\" entry signals the addition of \n the VL by using the \"changeType\" attribute of \"AffectedVirtualLink\" structure \n equal to \"ADDED\", and another \"AffectedVirtualLink\" entry signals the addition \n of externally visible VNF link ports of the VL by using the \"changeType\" equal \n to \"LINK_PORT_ADDED\".\nNOTE 4:\tA coordination action has timed out if the VNFM has not been able to read the \n \"Individual coordination action\" resource within a timeout interval after requesting \n the coordination to be started or to be cancelled. The length of the timeout interval \n is defined by means outside the scope of the present document.\nNOTE 5: The list of rejected coordinations may be garbage collected if the LCM operation\n occurrence has reached a terminal state, i.e. one of \"COMPLETED\", \"FAILED\" and \"ROLLED_BACK\".\n","type":"object","oneOf":[{"required":["changedInfo"]},{"required":["modificationsTriggeredByVnfPkgChange"]}],"required":["id","operationState","stateEnteredTime","startTime","vnfInstanceId","operation","isAutomaticInvocation","isCancelPending"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"operationState":{"description":"STARTING: The LCM operation is starting. PROCESSING: The LCM operation is currently in execution. COMPLETED: The LCM operation has been completed successfully. FAILED_TEMP: The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED: The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK: The LCM operation is currently being rolled back. ROLLED_BACK: The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible.\n","type":"string","enum":["STARTING","PROCESSING","COMPLETED","FAILED_TEMP","FAILED","ROLLING_BACK","ROLLED_BACK"]},"stateEnteredTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"startTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"grantId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"operation":{"description":"The enumeration LcmOpType defines the permitted values to represent VNF lifecycle operation types in VNF lifecycle management operation occurrence resources and VNF lifecycle management operation occurrence notifications.\nValue | Description ------|------------ INSTANTIATE | Represents the \"Instantiate VNF\" LCM operation. SCALE | Represents the \"Scale VNF\" LCM operation. SCALE_TO_LEVEL | Represents the \"Scale VNF to Level\" LCM operation. CHANGE_FLAVOUR | Represents the \"Change VNF Flavour\" LCM operation. TERMINATE | Represents the \"Terminate VNF\" LCM operation. HEAL | Represents the \"Heal VNF\" LCM operation. OPERATE | Represents the \"Operate VNF\" LCM operation. CHANGE_EXT_CONN | Represents the \"Change external VNF connectivity\" LCM operation. MODIFY_INFO | Represents the \"Modify VNF Information\" LCM operation. CREATE_SNAPSHOT | Represents the \"Create VNF Snapshot\" LCM operation. REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot\" LCM operation. CHANGE_VNFPKG | Represents the \"Change current VNF package\" LCM operation. SELECT_DEPL_MODS | Represents the “Select VNF deployable modules” LCM operation\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","MODIFY_INFO","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","CHANGE_VNFPKG","SELECT_DEPL_MODS"]},"isAutomaticInvocation":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"operationParams":{"description":"Input parameters of the LCM operation. This attribute shall be formatted according to the request data type of the related LCM operation. In addition, the provisions in clause 5.7 shall apply.\nThe following mapping between operationType and the data type of this attribute shall apply: * INSTANTIATE: InstantiateVnfRequest * SCALE: ScaleVnfRequest * SCALE_TO_LEVEL: ScaleVnfToLevelRequest * CHANGE_FLAVOUR: ChangeVnfFlavourRequest * OPERATE: OperateVnfRequest * HEAL: HealVnfRequest * CHANGE_EXT_CONN: ChangeExtVnfConnectivityRequest * TERMINATE: TerminateVnfRequest * MODIFY_INFO: VnfInfoModifications * CREATE_SNAPSHOT: CreateVnfSnapshotRequest * REVERT_TO_SNAPSHOT: RevertToVnfSnapshotRequest * CHANGE_VNFPKG: ChangeCurrentVnfPkgRequest * SELECT_DEPL_MODS: SelectVnfDeployableModulesRequest\n","type":"object"},"isCancelPending":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"cancelMode":{"description":"Cancellation mode. GRACEFUL: If the VNF LCM operation occurrence is in \"PROCESSING\" or \"ROLLING_BACK\" state, the VNFM shall not start any new resource management operation and shall wait for the ongoing resource management operations in the underlying system, typically the VIM, to finish execution or to time out. After that, the VNFM shall put the operation occurrence into the FAILED_TEMP state. If the VNF LCM operation occurrence is in \"STARTING\" state, the VNFM shall not start any resource management operation and shall wait for the granting request to finish execution or time out. After that, the VNFM shall put the operation occurrence into the ROLLED_BACK state. FORCEFUL: If the VNF LCM operation occurrence is in \"PROCESSING\" or \"ROLLING_BACK\" state, the VNFM shall not start any new resource management operation, shall cancel the ongoing resource management operations in the underlying system, typically the VIM, and shall wait for the cancellation to finish or to time out. After that, the VNFM shall put the operation occurrence into the FAILED_TEMP state. If the VNF LCM operation occurrence is in \"STARTING\" state, the VNFM shall not start any resource management operation and put the operation occurrence into the ROLLED_BACK state.\n","type":"string","enum":["GRACEFUL","FORCEFUL"]},"error":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}},"resourceChanges":{"description":"This attribute contains information about the cumulative changes to virtualised resources that were performed so far by the LCM operation since its start, if applicable.\n","type":"object","properties":{"affectedVnfcs":{"description":"Information about VNFC instances that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary VNFCs.\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer \n (i.e. the NFVO) to assist in correlating the resource changes performed during \n the LCM operation with the granted resources in a specific Grant exchange, which \n is identified by the \"grantId\" available in the \"Individual VNF lifecycle management \n operation occurrence\" and the \"id\" in the \"Individual Grant\".\n","type":"object","required":["id","vduId","changeType","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY For a temporary resource, an AffectedVnfc structure exists as long as the temporary resource exists.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY"]},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"affectedVnfcCpIds":{"description":"Identifiers of CP(s) of the VNFC instance that were affected by the change. Shall be present for those affected CPs of the VNFC instance that are associated to an external CP of the VNF instance. May be present for further affected CPs of the VNFC instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"addedStorageResourceIds":{"description":"References to VirtualStorage resources that have been added. Each value refers to a VirtualStorageResourceInfo item in the VnfInstance that was added to the VNFC. It shall be provided if at least one storage resource was added to the VNFC.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"removedStorageResourceIds":{"description":"References to VirtualStorage resources that have been removed. The value contains the identifier of a VirtualStorageResourceInfo item that has been removed from the VNFC, and might no longer exist in the VnfInstance. It shall be provided if at least one storage resource was removed from the VNFC.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"affectedVirtualLinks":{"description":"Information about VL instances that were affected during the lifecycle operation. See notes 1 and 3.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary VLs, and added or removed VNF link ports.\nNOTE 1:\tWhen signalling the addition (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) of VNF link ports, \n the \"networkResource\" and \"resourceDefinitionId\" attributes refer to the affected virtual link \n instance, not the link port instance. The resource handles of the affected VNF link ports can be \n found by dereferencing the identifiers in the \"vnfLinkPortIds\" attribute.\nNOTE 2:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to \n assist in correlating the resource changes performed during the LCM operation with the granted \n resources in a specific Grant exchange, which is identified by the \"grantId\" available in the \n \"Individual VNF lifecycle management operation occurrence\" and the \"id\" in the \"Individual Grant\".\n","type":"object","required":["id","vnfVirtualLinkDescId","changeType","networkResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change.\nPermitted values: -\tADDED -\tREMOVED -\tMODIFIED -\tTEMPORARY -\tLINK_PORT_ADDED -\tLINK_PORT_REMOVED For a temporary resource, an AffectedVirtualLink structure exists as long as the temporary resource exists. See note 1.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY","LINK_PORT_ADDED","LINK_PORT_REMOVED"]},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPortIds":{"description":"Identifiers of the link ports of the affected VL related to the change. Each identifier references a \"VnfLinkPortInfo\" structure.\nShall be set when changeType is equal to \"LINK_PORT_ADDED\" or \"LINK_PORT_REMOVED\", and the related \"VnfLinkPortInfo\" structures are present (case \"added\") or have been present (case \"removed\") in the \"VnfVirtualLinkResourceInfo\" or \"ExtManagedVirtualLinkInfo\" structures that are represented by the \"vnfVirtualLinkResource¬Info\" or \"extManagedVirtualLinkInfo\" attribute in the \"VnfInstance\" structure. See note 1.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"affectedExtLinkPorts":{"description":"Information about external VNF link ports that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added and deleted external link ports (link ports attached to external virtual links).\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to assist in correlating \n the resource changes performed during the LCM operation with the granted resources in a specific Grant exchange, which \n is identified by the \"grantId\" available in the \"Individual VNF lifecycle management operation occurrence\" and the \"id\" \n in the \"Individual Grant\".\n","type":"object","required":["id","changeType","extCpInstanceId","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: -\tADDED - MODIFIED -\tREMOVED\n","type":"string","enum":["ADDED","MODIFIED","REMOVED"]},"extCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"}}}},"affectedVirtualStorages":{"description":"Information about virtualised storage instances that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary virtual storage resources.\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to \n assist in correlating the resource changes performed during the LCM operation with the granted \n resources in a specific Grant exchange, which is identified by the \"grantId\" available in the \n \"Individual VNF lifecycle management operation occurrence\" and the \"id\" in the \"Individual Grant\".\n","type":"object","required":["id","virtualStorageDescId","changeType","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY For a temporary resource, an AffectedVirtualStorage structure exists as long as the temporary resource exists.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY"]},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"changedInfo":{"description":"This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource. The attributes that can be included consist of those requested to be modified explicitly in the \"VnfInfoModificationRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly e.g. when modifying the referenced VNF package.\nNOTE:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) \n was modified implicitly following a request to modify the \"vnfdId\" attribute, by \n copying the value of this attribute from the VNFD in the VNF Package identified by \n the \"vnfdId\" attribute.\n","type":"object","properties":{"vnfInstanceName":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfInstanceDescription":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vimConnectionInfo":{"description":"If present, this attribute signals modifications the \"vimConnectionInfo\" attribute array in \"VnfInstance\".\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfProductName":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"}}},"affectedVipCps":{"description":"Information about virtual IP CP instances that were affected during the execution of the lifecycle management operation.\n","type":"array","items":{"description":"This type provides information about added, deleted and modified virtual IP CP instances.\n","type":"object","required":["cpInstanceId","cpdId","changeType"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: -\tADDED -\tREMOVED -\tMODIFIED\n","type":"string","enum":["ADDED","REMOVED","MODIFIED"]}}}},"changedExtConnectivity":{"description":"Information about changed external connectivity, if applicable. See note 1.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"modificationsTriggeredByVnfPkgChange":{"description":"This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource when changing the current VNF package. The attributes that can be included consist of those requested to be modified explicitly in the \"ChangeCurrentVnfPkgRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly during the operation.\nNOTE 1:\tThis attribute represents the delta (semantics as per IETF RFC 7396, JSON Merge Patch) between the value \n of the attribute at the start of the \"Change current VNF package\" operation and the value of the attribute \n at its completion.\nNOTE 2:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) was modified implicitly \n during the related operation and contains a copy of the value of the related attribute from the VNFD in the \n VNF Package identified by the \"vnfdId\" attribute.\n","type":"object","properties":{"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"If present, this attribute signals the new value of the \"vnfProvider\" attribute in \"VnfInstance\". See note 2.\n","type":"string"},"vnfProductName":{"description":"If present, this attribute signals the new value of the \"vnfProductName\" attribute in \"VnfInstance\". See note 2.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vimConnectionInfo":{"description":"If present, this attribute signals the changes to VIM connection info that were passed in the related \"ChangeCurrentVnfPkgRequest\" structure.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"vnfSnapshotInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"lcmCoordinations":{"description":"Information about LCM coordination actions (see clause 10 in ETSI GS NFV-SOL002) related to this LCM operation occurrence.\n","type":"array","items":{"type":"object","required":["id","coordinationActionName","startTime","endpointType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"coordinationActionName":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"coordinationResult":{"description":"The enumeration LcmCoordResultType defines the permitted values to represent the result of executing an LCM coordination action. The coordination result also implies the action to be performed by the VNFM as the follow-up to this coordination. Value | Description ------|------------ CONTINUE | The related LCM operation shall be continued, staying in the state \"PROCESSING\". ABORT | The related LCM operation shall be aborted by transitioning into the state \"FAILED_TEMP\". CANCELLED | The coordination action has been cancelled upon request of the API consumer, i.e. the VNFM. The related LCM operation shall be aborted by transitioning into the state \"FAILED_TEMP\".\n","type":"string","enum":["CONTINUE","ABORT","CANCELLED"]},"startTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"endTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"delay":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"endpointType":{"description":"The endpoint type used by this coordination action. Valid values: •\tMGMT: coordination with other operation supporting management systems (e.g. EM) •\tVNF: coordination with the VNF instance\n","type":"string","enum":["MGMT","VNF"]}}}},"rejectedLcmCoordinations":{"description":"Information about LCM coordination actions (see clause 10 in ETSI GS NFV-SOL002) that were rejected by 503 error which means they can be tried again after a delay. See note 5.\n","type":"array","items":{"type":"object","required":["coordinationActionName","rejectionTime","endpointType","delay"],"properties":{"coordinationActionName":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"rejectionTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"delay":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"endpointType":{"description":"The endpoint type used by this coordination action. Valid values: •\tMGMT: coordination with other operation supporting management systems (e.g. EM) •\tVNF: coordination with the VNF instance\n","type":"string","enum":["MGMT","VNF"]}}}},"warnings":{"description":"Warning messages that were generated while the operation was executing.\nIf the operation has included LCM coordination actions and these have resulted in warnings, such warnings should be added to this attribute.\n","type":"array","items":{"type":"string"}},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self","vnfInstance"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"grant":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"cancel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"retry":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"rollback":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"fail":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"FailVnfLcmOpOcc.Post.404":{"description":"404 NOT FOUND\n\nShall be returned upon the following error: The API\nproducer did not find a current representation for the\ntarget resource or is not willing to disclose that one\nexists.\nThe general cause for this error and its handling is\nspecified in clause 6.4 of ETSI GS NFV-SOL 013 [8],\nincluding rules for the presence of the response\nbody.\nSpecifically in case of this task resource, the\nresponse code 404 shall also be returned if the task\nis not supported for the VNF LCM operation\noccurrence represented by the parent resource,\nwhich means that the task resource consequently\ndoes not exist.\nIn this case, the response body shall be present, and\nshall contain a ProblemDetails structure, in which the\n\"detail\" attribute shall convey more information about\nthe error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"FailVnfLcmOpOcc.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the VNF LCM operation\noccurrence.\nTypically, this is due to the fact that the VNF LCM\noperation occurrence is not in FAILED_TEMP state,\nor another error handling action is starting, such as\nretry or rollback.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"CancelVnfLcmOpOcc.Post.202":{"description":"202 ACCEPTED\n\nShall be returned when the request has been accepted for processing.\nThe response shall have an empty message content.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"CancelVnfLcmOpOcc.Post.404":{"description":"404 NOT FOUND\n\nShall be returned upon the following error: The API\nproducer did not find a current representation for the\ntarget resource or is not willing to disclose that one\nexists.\nThe general cause for this error and its handling is\nspecified in clause 6.4 of ETSI GS NFV-SOL 013 [8],\nincluding rules for the presence of the response\nbody.\nSpecifically in case of this task resource, the\nresponse code 404 shall also be returned if the task\nis not supported for the VNF LCM operation\noccurrence represented by the parent resource,\nwhich means that the task resource consequently\ndoes not exist.\nIn this case, the response body shall be present, and\nshall contain a ProblemDetails structure, in which the\n\"detail\" attribute shall convey more information about\nthe error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"CancelVnfLcmOpOcc.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the VNF LCM operation\noccurrence.\nTypically, this is due to the fact that the operation\noccurrence is not in STARTING, PROCESSING or\nROLLING_BACK state.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"Subscriptions.Post.201":{"description":"201 CREATED\n\nShall be returned when the subscription has been created successfully.\nThe response body shall contain a representation of the created \"Individual subscription\" resource.\nThe HTTP response shall include a \"Location\" HTTP header that points to the created\n\"Individual subscription\" resource.\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a subscription related to notifications about VNF lifecycle changes.\n","type":"object","required":["id","callbackUri","verbosity","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications about VNF lifecycle changes.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of \n the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdId"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tVnfLcmOperationOccurrenceNotification -\tVnfIdentifierCreationNotification -\tVnfIdentifierDeletionNotification See note.\n","type":"array","items":{"type":"string","enum":["VnfLcmOperationOccurrenceNotification","VnfIdentifierCreationNotification","VnfIdentifierDeletionNotification"]}},"operationTypes":{"description":"Match particular VNF lifecycle operation types for the notification of type VnfLcmOperationOccurrenceNotification. May be present if the \"notificationTypes\" attribute contains the value \"VnfLcmOperationOccurrenceNotification\", and shall be absent otherwise.\n","type":"array","items":{"description":"The enumeration LcmOpType defines the permitted values to represent VNF lifecycle operation types in VNF lifecycle management operation occurrence resources and VNF lifecycle management operation occurrence notifications.\nValue | Description ------|------------ INSTANTIATE | Represents the \"Instantiate VNF\" LCM operation. SCALE | Represents the \"Scale VNF\" LCM operation. SCALE_TO_LEVEL | Represents the \"Scale VNF to Level\" LCM operation. CHANGE_FLAVOUR | Represents the \"Change VNF Flavour\" LCM operation. TERMINATE | Represents the \"Terminate VNF\" LCM operation. HEAL | Represents the \"Heal VNF\" LCM operation. OPERATE | Represents the \"Operate VNF\" LCM operation. CHANGE_EXT_CONN | Represents the \"Change external VNF connectivity\" LCM operation. MODIFY_INFO | Represents the \"Modify VNF Information\" LCM operation. CREATE_SNAPSHOT | Represents the \"Create VNF Snapshot\" LCM operation. REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot\" LCM operation. CHANGE_VNFPKG | Represents the \"Change current VNF package\" LCM operation. SELECT_DEPL_MODS | Represents the “Select VNF deployable modules” LCM operation\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","MODIFY_INFO","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","CHANGE_VNFPKG","SELECT_DEPL_MODS"]}},"operationStates":{"description":"Match particular LCM operation state values as reported in notifications of type VnfLcmOperationOccurrenceNotification. May be present if the \"notificationTypes\" attribute contains the value \"VnfLcmOperationOccurrenceNotification\", and shall be absent otherwise.\n","type":"array","items":{"description":"STARTING: The LCM operation is starting. PROCESSING: The LCM operation is currently in execution. COMPLETED: The LCM operation has been completed successfully. FAILED_TEMP: The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED: The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK: The LCM operation is currently being rolled back. ROLLED_BACK: The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible.\n","type":"string","enum":["STARTING","PROCESSING","COMPLETED","FAILED_TEMP","FAILED","ROLLING_BACK","ROLLED_BACK"]}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"verbosity":{"description":"The enumeration LcmOpOccNotificationVerbosityType provides values to control the verbosity of LCM operation occurrence notifications. * FULL: This signals a full notification which contains all change details. * SHORT: This signals a short notification which omits large-volume change details to reduce the size of data to be sent via the notification mechanism.\n","type":"string","enum":["FULL","SHORT"]},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"Subscriptions.Post.303":{"description":"303 See Other\n\nShall be returned if a subscription with the same\ncallback URI and the same filter already exists\nand the policy of the VNFM is to not create\nredundant subscriptions.\nThe HTTP response shall include a \"Location\"\nHTTP header that contains the resource URI of\nthe existing \"Individual subscription\" resource.\nThe response body shall be empty.\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}}},"Subscriptions.Post.422":{"description":"422 Unprocessable Content\n\nShall be returned upon the following error: The content type of the message content is supported\nand the message content of a request contains syntactically correct data but the data cannot be processed.\nThe general cause for this error and its handling is specified in clause 6.4 of ETSI\nGS NFV-SOL 013 [8], including rules for the presence of the response body.\nSpecifically in case of this resource, the response code 422 shall also be returned if the VNFM has\ntested the Notification endpoint as described in clause 5.4.20.3.2 and the test has failed.\nIn this case, the \"detail\" attribute in the \"ProblemDetails\" structure shall convey more\ninformation about the error.\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"Subscriptions.Get.200":{"description":"200 OK\n\nShall be returned when the list of subscriptions has been queried successfully.\nThe response body shall contain in an array the representations of all active subscriptions of\nthe functional block that invokes the method, i.e. zero or more representations of lifecycle change\nnotification subscriptions as defined in clause 5.5.2.16.\nIf the \"filter\" URI parameter was supplied in the request, the data in the response body shall have been\ntransformed according to the rules specified in clause 5.2.2 of ETSI GS NFV-SOL 013.\nIf the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013\nfor this resource, inclusion of the Link HTTP header in this response shall follow the provisions\nin clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a subscription related to notifications about VNF lifecycle changes.\n","type":"object","required":["id","callbackUri","verbosity","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications about VNF lifecycle changes.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of \n the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdId"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tVnfLcmOperationOccurrenceNotification -\tVnfIdentifierCreationNotification -\tVnfIdentifierDeletionNotification See note.\n","type":"array","items":{"type":"string","enum":["VnfLcmOperationOccurrenceNotification","VnfIdentifierCreationNotification","VnfIdentifierDeletionNotification"]}},"operationTypes":{"description":"Match particular VNF lifecycle operation types for the notification of type VnfLcmOperationOccurrenceNotification. May be present if the \"notificationTypes\" attribute contains the value \"VnfLcmOperationOccurrenceNotification\", and shall be absent otherwise.\n","type":"array","items":{"description":"The enumeration LcmOpType defines the permitted values to represent VNF lifecycle operation types in VNF lifecycle management operation occurrence resources and VNF lifecycle management operation occurrence notifications.\nValue | Description ------|------------ INSTANTIATE | Represents the \"Instantiate VNF\" LCM operation. SCALE | Represents the \"Scale VNF\" LCM operation. SCALE_TO_LEVEL | Represents the \"Scale VNF to Level\" LCM operation. CHANGE_FLAVOUR | Represents the \"Change VNF Flavour\" LCM operation. TERMINATE | Represents the \"Terminate VNF\" LCM operation. HEAL | Represents the \"Heal VNF\" LCM operation. OPERATE | Represents the \"Operate VNF\" LCM operation. CHANGE_EXT_CONN | Represents the \"Change external VNF connectivity\" LCM operation. MODIFY_INFO | Represents the \"Modify VNF Information\" LCM operation. CREATE_SNAPSHOT | Represents the \"Create VNF Snapshot\" LCM operation. REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot\" LCM operation. CHANGE_VNFPKG | Represents the \"Change current VNF package\" LCM operation. SELECT_DEPL_MODS | Represents the “Select VNF deployable modules” LCM operation\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","MODIFY_INFO","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","CHANGE_VNFPKG","SELECT_DEPL_MODS"]}},"operationStates":{"description":"Match particular LCM operation state values as reported in notifications of type VnfLcmOperationOccurrenceNotification. May be present if the \"notificationTypes\" attribute contains the value \"VnfLcmOperationOccurrenceNotification\", and shall be absent otherwise.\n","type":"array","items":{"description":"STARTING: The LCM operation is starting. PROCESSING: The LCM operation is currently in execution. COMPLETED: The LCM operation has been completed successfully. FAILED_TEMP: The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED: The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK: The LCM operation is currently being rolled back. ROLLED_BACK: The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible.\n","type":"string","enum":["STARTING","PROCESSING","COMPLETED","FAILED_TEMP","FAILED","ROLLING_BACK","ROLLED_BACK"]}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"verbosity":{"description":"The enumeration LcmOpOccNotificationVerbosityType provides values to control the verbosity of LCM operation occurrence notifications. * FULL: This signals a full notification which contains all change details. * SHORT: This signals a short notification which omits large-volume change details to reduce the size of data to be sent via the notification mechanism.\n","type":"string","enum":["FULL","SHORT"]},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"IndividualSubscription.Get.200":{"description":"200 OK\n\nShall be returned when information about an individual subscription has been read successfully.\nThe response body shall contain a representation of the \"Individual subscription\" resource.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a subscription related to notifications about VNF lifecycle changes.\n","type":"object","required":["id","callbackUri","verbosity","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications about VNF lifecycle changes.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of \n the notification types to facilitate automated code generation systems.\n","type":"object","properties":{"vnfInstanceSubscriptionFilter":{"description":"This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfdId"]},{"required":["vnfProductsFromProviders"]}]},{"oneOf":[{"required":["vnfInstanceIds"]},{"required":["vnfInstanceNames"]}]}],"properties":{"vnfdIds":{"description":"If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. See note 1.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfProductsFromProviders":{"description":"If present, match VNF instances that belong to VNF products from certain providers. See note 1.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNF provider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfInstanceIds":{"description":"If present, match VNF instances with an instance identifier listed in this attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfInstanceNames":{"description":"If present, match VNF instances with a VNF Instance Name listed in this attribute. See note 2.\n","type":"array","items":{"type":"string"}}}},"notificationTypes":{"description":"Match particular notification types. \nPermitted values: -\tVnfLcmOperationOccurrenceNotification -\tVnfIdentifierCreationNotification -\tVnfIdentifierDeletionNotification See note.\n","type":"array","items":{"type":"string","enum":["VnfLcmOperationOccurrenceNotification","VnfIdentifierCreationNotification","VnfIdentifierDeletionNotification"]}},"operationTypes":{"description":"Match particular VNF lifecycle operation types for the notification of type VnfLcmOperationOccurrenceNotification. May be present if the \"notificationTypes\" attribute contains the value \"VnfLcmOperationOccurrenceNotification\", and shall be absent otherwise.\n","type":"array","items":{"description":"The enumeration LcmOpType defines the permitted values to represent VNF lifecycle operation types in VNF lifecycle management operation occurrence resources and VNF lifecycle management operation occurrence notifications.\nValue | Description ------|------------ INSTANTIATE | Represents the \"Instantiate VNF\" LCM operation. SCALE | Represents the \"Scale VNF\" LCM operation. SCALE_TO_LEVEL | Represents the \"Scale VNF to Level\" LCM operation. CHANGE_FLAVOUR | Represents the \"Change VNF Flavour\" LCM operation. TERMINATE | Represents the \"Terminate VNF\" LCM operation. HEAL | Represents the \"Heal VNF\" LCM operation. OPERATE | Represents the \"Operate VNF\" LCM operation. CHANGE_EXT_CONN | Represents the \"Change external VNF connectivity\" LCM operation. MODIFY_INFO | Represents the \"Modify VNF Information\" LCM operation. CREATE_SNAPSHOT | Represents the \"Create VNF Snapshot\" LCM operation. REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot\" LCM operation. CHANGE_VNFPKG | Represents the \"Change current VNF package\" LCM operation. SELECT_DEPL_MODS | Represents the “Select VNF deployable modules” LCM operation\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","MODIFY_INFO","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","CHANGE_VNFPKG","SELECT_DEPL_MODS"]}},"operationStates":{"description":"Match particular LCM operation state values as reported in notifications of type VnfLcmOperationOccurrenceNotification. May be present if the \"notificationTypes\" attribute contains the value \"VnfLcmOperationOccurrenceNotification\", and shall be absent otherwise.\n","type":"array","items":{"description":"STARTING: The LCM operation is starting. PROCESSING: The LCM operation is currently in execution. COMPLETED: The LCM operation has been completed successfully. FAILED_TEMP: The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED: The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK: The LCM operation is currently being rolled back. ROLLED_BACK: The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible.\n","type":"string","enum":["STARTING","PROCESSING","COMPLETED","FAILED_TEMP","FAILED","ROLLING_BACK","ROLLED_BACK"]}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"verbosity":{"description":"The enumeration LcmOpOccNotificationVerbosityType provides values to control the verbosity of LCM operation occurrence notifications. * FULL: This signals a full notification which contains all change details. * SHORT: This signals a short notification which omits large-volume change details to reduce the size of data to be sent via the notification mechanism.\n","type":"string","enum":["FULL","SHORT"]},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualSubscription.Delete.204":{"description":"204 NO CONTENT\n\nShall be returned when the \"Individual subscription\" resource has been deleted successfully.\nThe response body shall be empty.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"CreateVnfSnapshotTask.Post.202":{"description":"202 ACCEPTED\n\nShall be returned when the request was accepted for processing, but the processing\nhas not been completed.\nThe response body shall be empty.\nThe HTTP response shall include a \"Location\" HTTP header that contains the URI of\nthe newly-created \"VNF LCM operation occurrence\" resource corresponding to the operation.\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"CreateVnfSnapshotTask.Post.404":{"description":"404 NOT FOUND\n\nSShall be returned upon the following error: The API producer did not find a current representation for\nthe target resource or is not willing to disclose that one exists.\nThe general cause for this error and its handling is specified in clause 6.4 of ETSI\nGS NFV-SOL 013 [8], including rules for the presence of the response body.\nSpecifically in case of this task resource, the response code 404 shall also be returned if the task\nis not supported for the VNF instance represented by the parent resource, which means that the task\nresource consequently does not exist.\nIn this case, the response body shall be present, and shall contain a ProblemDetails structure, in\nwhich the \"detail\" attribute shall convey more information about the error\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"CreateVnfSnapshotTask.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the VNF\ninstance resource is in NOT_INSTANTIATED state,\nor that another lifecycle management operation is\nongoing.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"CreateVnfSnapshotTask.Post.422":{"description":"422 Unprocessable Content\n\nShall be returned upon the following error: The\ncontent type of the message content is supported and\nthe message content of a request contains syntactically\ncorrect data but the data cannot be processed.\nThe general cause for this error and its handling is\nspecified in clause 6.4 of ETSI\nGS NFV-SOL 013 [8], including rules for the\npresence of the response body.\nSpecifically in case of this resource, the response\ncode 422 shall also be returned if the provided\nidentifier of the target \"Individual VNF snapshot\"\nresource for the VNF snapshot is invalid.\nIn this case, the \"detail\" attribute in the\n\"ProblemDetails\" structure shall convey more\ninformation about the error\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"RevertToVnfSnapshotTask.Post.202":{"description":"202 ACCEPTED\n\nShall be returned when the request was accepted for processing, but the processing has\nnot been completed.\nThe response body shall be empty.\nThe HTTP response shall include a \"Location\" HTTP header that contains the URI of\nthe newly-created \"VNF LCM operation occurrence\" resource corresponding to the operation.\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"RevertToVnfSnapshotTask.Post.404":{"description":"404 NOT FOUND\n\nShall be returned upon the following error: The API\nproducer did not find a current representation for the\ntarget resource or is not willing to disclose that one\nexists.\nThe general cause for this error and its handling is\nspecified in clause 6.4 of ETSI\nGS NFV-SOL 013 [8], including rules for the\npresence of the response body.\nSpecifically in case of this task resource, the\nresponse code 404 shall also be returned if the task\nis not supported for the VNF instance represented\nby the parent resource, which means that the task\nresource consequently does not exist.\nIn this case, the response body shall be present,\nand shall contain a ProblemDetails structure, in\nwhich the \"detail\" attribute shall convey more\ninformation about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"RevertToVnfSnapshotTask.Post.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the VNF\ninstance resource is in NOT_INSTANTIATED state,\nor that another lifecycle management operation is\nongoing.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"VnfSnapshots.Post.201":{"description":"201 CREATED\n\nShall be returned when an \"Individual VNF snapshot\" resource has been created\nsuccessfully.\nThe response body shall contain a representation of the new \"Individual VNF snapshot\"\nresource, as defined in clause 5.5.2.22.\nThe HTTP response shall include a \"Location\" HTTP header that contains the resource URI\nof the \"Individual VNF snapshot\" resource.\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents an \"Individual VNF snapshot\" resource.\n","type":"object","required":["id","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfSnapshotPkgId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfSnapshot":{"description":"This type represents a VNF snapshot.\n","type":"object","required":["id","vnfInstanceId","triggeredAt","vnfdId","vnfInfo","vnfcSnapshots"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"creationStartedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"creationFinishedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstance":{"description":"This type represents a VNF instance.\nNOTE:\tClause B.3.2 provides examples illustrating the relationship among the different run-time \n information elements (CP, VL and link ports) used to represent the connectivity of a VNF.\n\nNOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist between \n the previous and the newly referred VNF package, i.e. when the new VNFD is changed with \n respect to the previous VNFD in other aspects than merely referencing to other VNF software \n images. In order to avoid misalignment of the VnfInstance with the current VNF's on-boarded \n VNF Package, the values of attributes in the VnfInstance that have corresponding attributes \n in the VNFD shall be kept in sync with the values in the VNFD.\nNOTE 2:\tETSI GS NFV-SOL 001 [14] specifies the structure and format of the VNFD based on TOSCA specifications. NOTE 3:\tVNF configurable properties are sometimes also referred to as configuration parameters applicable \n to a VNF. Some of these are set prior to instantiation and cannot be modified if the VNF is instantiated, \n some are set prior to instantiation (are part of initial configuration) and can be modified later, \n and others can be set only after instantiation. The applicability of certain configuration may \n depend on the VNF and the required operation of the VNF at a certain point in time.\nNOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes \n of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared in the VNFD with a defined \n initial value. The defined initial values can be declared in the VNFD, and/or, in case of \"metadata\", \n obtained from the \"CreateVnfRequest\" structure. Child attributes of \"vnfConfigurableProperties\", \n \"metadata\" and \"extensions\" that have no defined initial value shall not be created, in order to be \n consistent with the semantics of the JSON Merge Patch method (see IETF RFC 7396) that interprets null \n values as deletion request.\nNOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a \n multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same \n VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed \n multi-site VL instance (refer to clause 5.5.3.3).\nNOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity, they shall \n not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\nNOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing \n the trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\nNOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the \n VNF LCM operation explicitly indicates the scale level for the aspect.\nNOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n","type":"object","required":["id","vnfdId","vnfProvider","vnfProductName","vnfSoftwareVersion","vnfdVersion","instantiationState","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceName":{"description":"Name of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfInstanceDescription":{"description":"Human-readable description of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"Provider of the VNF and the VNFD. The value is copied from the VNFD.\n","type":"string"},"vnfProductName":{"description":"Name to identify the VNF Product. The value is copied from the VNFD.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vimConnectionInfo":{"description":"Information about VIM or CISM connections to be used for managing the resources for the VNF instance. The keys of the map, each of which identifies information about a particular VIM connection, are managed by the NFVO and referenced from other data structures via the \"vimConnectionId\" attribute. This attribute shall only be supported and present if - the resources of at least of the VNFCs are managed by a VIM and VNF-related resource management in direct mode is applicable. - the resources of at least of the VNFCs are managed by a CISM. This attribute can be modified with the PATCH method. If VIM connection information is provisioned to the VNFM by means outside the scope of the present document, the information in the \"vimConnectionInfo\" attribute provides necessary information for binding the VnfInstance representing the \"Individual VNF instance\" to the applicable VIM connection information used to perform resource management for the VNF instance. See also the definition of the \"VimConnectionInfo\" in clause 4.4.1.6.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"cirConnectionInfo":{"description":"Information about the CIR connection for managing OS container images for the VNF instance. Shall be present when all or part of the VNF is realized by a set of OS containers and shall be absent otherwise.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mciopRepositoryInfo":{"description":"Information about the MCIOP repository for the VNF instance. Shall be present when all or part of the VNF is realized by a set of OS containers and shall be absent otherwise. See note 1.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"certificateInfo":{"description":"This type provides input information related to certificate and certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateConfigurationInfo":{"description":"This type provides input information related to certificate management.\n","type":"object","required":["securityPolicy"],"properties":{"certificateBaseProfile":{"description":"Information for certificate profile.","type":"array","items":{"description":"NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\nThis type provides input information to override certificate base profile for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"description":"Issuer of certificates. See note.","type":"string"},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to the subject of the certificate.\nNOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of the certification target subject FQDN. Can be set empty when this certificate is used for encrypted communication using IP address. See note.\n","type":"string"},"organization":{"description":"Information of the certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of the certification target subject Country. See note.","type":"string"},"state":{"description":"Information of the certification target subject State. See note.","type":"string"},"locality":{"description":"Information of the certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of the certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"description":"Basic constraints of certificates. See note.","type":"string"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [14], clause 7.1.19.4). See note.\n","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}}},"securityPolicy":{"description":"Information for security policy to be satisfied for certificate.","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"number"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"number"}}}},"delegationSupportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"cmfInfo":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["id","endPoint","supportedProtocol"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"endPoint":{"description":"End point of CMF instance.","type":"object","properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocol":{"description":"Supported protocols by CMF instance.","type":"array","items":{"description":"Supported protocol by CMF instance.","type":"string","enum":["CMP","CMPv2","EST","SCEP"]}},"certificateChain":{"description":"Certificate chain that this CMF provides.","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"certificateContents":{"description":"Information for contents of issued certificates. The information contained in this attribute may be updated over time during the VNF LCM, e.g., certificate(s) renewal.\n","type":"array","items":{"description":"This type provides input information related to certificate content.\nNOTE: The CertificateDesc data type is defined in clause 7.1.19.2 of ETSI GS NFV IFA 011 [10].\n","type":"object","required":["id","certificateDescId","certificateType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"certificateType":{"description":"Type of this certificate.","type":"string","enum":["VNFCI_CERT","VNFOAM_CERT"]},"supportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"version":{"description":"A version.\n","type":"string"},"serialNumber":{"description":"Serial number of this certificate.","type":"integer"},"signatureAlgorithm":{"description":"Algorithm of this certificate's signature.","type":"string"},"issuer":{"description":"Issuer of this certificate.","type":"string"},"notBefore":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"notAfter":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"subject":{"description":"Subject of this certificate.","type":"string"},"publicKeyAlgorithm":{"description":"Algorithm of this certificate's public key.","type":"string"},"publicKey":{"description":"Public key of this certificate.","type":"string"},"certificateExtensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"instantiationState":{"description":"The instantiation state of the VNF. Permitted values: - NOT_INSTANTIATED: The VNF instance is terminated or not instantiated. - INSTANTIATED: The VNF instance is instantiated.\n","type":"string","enum":["NOT_INSTANTIATED","INSTANTIATED"]},"instantiatedVnfInfo":{"description":"Information specific to an instantiated VNF instance. This attribute shall be present if the instantiateState attribute value is INSTANTIATED.\n","type":"object","required":["flavourId","vnfState"],"properties":{"flavourId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfState":{"description":"STARTED: The VNF instance is up and running. STOPPED: The VNF instance has been shut down.\n","type":"string","enum":["STARTED","STOPPED"]},"vnfPowerState":{"description":"This type represents information about the power state of a VNF instance.\n","type":"object","required":["powerProfileId","name"],"properties":{"powerProfileId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Name of the power profile as provided in the VNFD.\n","type":"string"},"powerConsumptionInfo":{"description":"This type represents information about estimated power consumption of the resources associated with the power profile, as provided in the VNFD.\n","type":"object","required":["minPowerConsumption","maxPowerConsumption","averagePowerConsumption"],"properties":{"minPowerConsumption":{"description":"Minimum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"maxPowerConsumption":{"description":"Maximum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"averagePowerConsumption":{"description":"Average power consumption of this power profile. Unit is KW/h.\n","type":"integer"}}}}},"scaleStatus":{"description":"Scale status of the VNF, one entry per aspect. Represents for every scaling aspect how \"big\" the VNF has been scaled w.r.t. that aspect.\nThis attribute shall be present if the VNF supports scaling. See clause B.2 for an explanation of VNF scaling.\nFor an aspect that has not been deployed because the related deployableModule has not been selected, it indicates the scale level that has been requested in the instantiation or in a scaling operation, or, if none has been requested in any of them, the scale level applicable to the aspect based on the default instantiation level. See note 8.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"maxScaleLevels":{"description":"Maximum allowed scale levels of the VNF, one entry per aspect. This attribute shall be present if the VNF supports scaling.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"selectedDeployableModule":{"description":"References a currently selected deployable module, as defined in the VNFD, that has already completed the instantiation of its VNFCs.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceCapacityDefinition":{"description":"Shows current values of VDU attributes related to resource capacity, if different to the default values from the VNFD, as indicated in the (one or more) request(s) of all completed VNF LCM operation(s) that contain this attribute. If an attribute value has been modified multiple times, only the last value is shown. The values indicated in this attribute are applicable to all VNFC instances based on the VDU to which the resourceCapacityDefinition is related.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes.\nThe tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request.\nAt most one tag can be included when the data type is used in a VNF LCM operation request.\nWhen the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.\n","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced.\n","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute 'type' indicates OSCONTAINER and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource. See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resource property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for this virtual compute descriptor. The value is a numberthat indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) that indicates the valid vaues for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"extCpInfo":{"description":"Information about the external CPs exposed by the VNF instance. When trunking is enabled, the list of entries includes both, external CPs corresponding to parent ports of a trunk, and external CPs associated to sub-ports of a trunk.See note 7.\n","type":"array","items":{"description":"This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n","type":"object","required":["id","cpdId","cpConfigId","cpProtocolInfo"],"oneOf":[{"required":["associatedVnfcCpId"]},{"required":["associatedVipCpId"]},{"required":["associatedVnfVirtualLinkId"]}],"properties":{"id":{"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"},"cpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extLinkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"associatedVnfcCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVipCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVirtualCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVnfVirtualLinkId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 3 and 4.\nIt shall be present if the external CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNF CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpSecurityGroupInfo":{"description":"This type provides the list of active security group rules applied to an external CP instance. The type identifies which \"SecurityGroupRule\" specified in the VNFD are activated and the values of its attributes.\n","type":"object","required":["securityGroupRuleId","etherType","protocol","portRangeMin","portRangeMax"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"description":{"description":"Human readable description of the security group rule.\n","type":"string"},"etherType":{"description":"Indicates the protocol carried over the Ethernet layer. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"protocol":{"description":"Indicates the protocol carried over the IP layer. Permitted values: any protocol defined in the IANA protocol registry (refer to clause 9.10.1.2 ofd ETSI GS NFV-SOL 001 for further information).\n","type":"string"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule.\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule.\n","type":"integer"}}}}}},"vipCpInfo":{"description":"VIP CPs that are part of the VNF instance. Shall be present when that particular VIP CP of the VNFC instance is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","minItems":1,"items":{"description":"This type provides information related to virtual IP (VIP) CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["cpInstanceId","cpdId"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for layer 3. There may be one cpProtocolInfo for layer 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"associatedVnfcCpIds":{"description":"Identifiers of the VnfcCps that share the virtual IP address allocated to the VIP CP instance. See note.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualCpInfo":{"description":"Virtual CPs that are part of the VNF instance. Shall be present when a particular Virtual CP is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","items":{"description":"This type provides information related to a virtual CP instance of a VNF.\nNOTE 1: A consumer of the VNF LCM interface can learn the actual VNFC instances implementing the service accessible via the virtual CP instance by querying the \"vnfcResourceInfo\" from the \"InstantiatedVnfInfo\" \n and filtering by corresponding \"vduIds\" values.\nNOTE 2: The information can be omitted because it is already available as part of the external CP information in the VnfExtCpInfo structure.\n","type":"object","required":["cpInstanceId","cpdId","resourceHandle","vduIds"],"properties":{"cpInstanceId":{"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"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for each layer protocol supported. This attribute may be omitted if the virtual CP is exposed as an external CP. See note 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vduIds":{"description":"Reference to the VDU(s) which implement the service accessible via the virtual CP instance. See note 1.\n","type":"array","minItems":1,"items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"additionalServiceInfo":{"description":"Additional service identification information of the virtual CP instance.\n","type":"array","items":{"description":"This type provides additional service information of the virtual CP instance used to expose properties of the virtual CP to NFV-MANO.\nNOTE: This attribute shall only be present if additional information is needed to identify the service termination within the VNF, such as for example a URL path information in an HTTP request required \n to allow a single virtual CP IP address to be used for several HTTP based services that use the \n same port number.\n","type":"object","required":["portInfo"],"properties":{"portInfo":{"description":"Service port numbers exposed by the virtual CP instance.\n","minItems":1,"type":"array","items":{"description":"This type describes the service identifying port properties exposed by the virtual CP instance.\n","type":"object","required":["name","port","portConfigurable"],"properties":{"name":{"description":"The name of the port exposed by the virtual CP instance.\n","type":"string"},"protocol":{"description":"The L4 protocol for this port exposed by the virtual CP instance.\nPermitted values: - TCP - UDP - SCTP\n","type":"string","enum":["TCP","UDP","SCTP"]},"port":{"description":"The L4 port number exposed by the virtual CP instance.\n","type":"integer"},"portConfigurable":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"}}}},"serviceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"extVirtualLinkInfo":{"description":"Information about the external VLs the VNF instance is connected to.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extManagedVirtualLinkInfo":{"description":"Information about the externally-managed internal VLs of the VNF instance. See notes 5 and 6.\n","type":"array","items":{"description":"This type provides information about an externally-managed virtual link. Note: Both \"vnfLinkPort\" and \"vnfNetAttDefResource\" attributes can be present in an \"ExtManagedVirtualLinkInfo\" to indicate that a single internal virtual link is providing connectivity for both VM-based and container-based \n VNFCs.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPorts":{"description":"Link ports of this VL. See note.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"vnfNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL. See note.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"extManagedMultisiteVirtualLinkId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"routingResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"monitoringParameters":{"description":"Active monitoring parameters.\n","type":"array","items":{"description":"This type represents a monitoring parameter that is tracked by the VNFM,\n","type":"object","required":["id","performanceMetric"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human readable name of the monitoring parameter, as defined in the VNFD.\n","type":"string"},"performanceMetric":{"description":"Performance metric that is monitored. This attribute shall contain the related \"Measurement Name\" value as defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"}}}},"localizationLanguage":{"description":"Information about localization language of the VNF (includes e.g. strings in the VNFD). The localization languages supported by a VNF can be declared in the VNFD, and localization language selection can take place at instantiation time. The value shall comply with the format defined in IETF RFC 5646.\n","type":"string"},"vnfcResourceInfo":{"description":"Information about the virtualised compute and storage resources used by the VNFCs of the VNF instance.\n","type":"array","items":{"description":"This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure of\n information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n a) For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n b) For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\nNOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on \n TOSCA specifications.\nNOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an \n internal VL that exposes an external CP. A VNFC CP is \"exposed as\" an external \n CP if it is connected directly to an external VL.\nNOTE 3:\tThe information can be omitted because it is already available as part of the \n external CP information.\nNOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\"\n structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVnfc\" structure in the VNF LCM operation occurrence notifications\n or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\nNOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment\n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. \nNOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n","type":"object","required":["id","vduId","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResourceIds":{"description":"References to the VirtualStorage resources or references to Storage MCIOs. The value refers to a VirtualStorageResourceInfo item in the VnfInstance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcCpInfo":{"description":"CPs of the VNFC instance. Shall be present when that particular CP of the VNFC instance is exposed as an external CP of the VNF instance or is connected to an external CP of the VNF instance. See note 2. May be present otherwise. See note 7.\n","type":"array","items":{"type":"object","required":["id","cpdId"],"properties":{"id":{"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"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP. May be omitted if the VNFC CP is exposed as an external CP. See note 3.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"parentCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 5 and 6. It shall be present if the internal CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfVirtualLinkResourceInfo":{"description":"Information about the virtualised network resources used by the VLs of the VNF instance. See note 6.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by an internal VL instance in a VNF instance.\nNote: If only the value or the presence of this attribute is changed in the \"VnfVirtualLinkResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including\n a related \"AffectedVirtualLink\" structure in the VNF LCM operation occurrence notifications or the\n \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLinkPorts":{"description":"Links ports of this VL. Shall be present when the linkPort is used for external connectivity by the VNF (refer to VnfLinkPortInfo). May be present otherwise.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualStorageResourceInfo":{"description":"Information on the virtualised storage resource(s) used as storage for the VNF instance.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance.\nNote: If only the value or the presence of this attribute is changed in the \"VirtualStorageResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVirtualStorage\" structure in the VNF LCM operation occurrence\n notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","virtualStorageDescId","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mcioInfo":{"description":"Information on the MCIO(s) representing VNFC instance(s) realized by one or a set of OS containers and created from the same VDU for the VNF instance.\n","type":"array","items":{"description":"This type provides information about an MCIO representing the set of VNFC instances realized by one or a set of OS containers which have been created based on the same VDU. Within the CISM, an MCIO controller monitors the actual state of an MCIO representing the set of VNFC instances realized by one or a set of OS containers and compare it to the desired state For an MCIO related to a VDU that has the attribute isNumOfInstancesClusterBased set to FALSE the desired state is specified in the respective declarative descriptor. For an MCIO related to a VDU that has the attribute isNumOfInstancesClusterBased set to TRUE, the desired state is determined by the number of CIS-nodes in the cluster that fulfil the VDU requirements.as specified in the respective declarative descriptor. It triggers actions toward the CIS to align the actual to the desired state. Monitoring the actual state includes monitoring the number of MCIO instances available at any specific point in time. In addition, an MCIO controller maintains properties and runtime information on the MCIO instances which have been created based on the same VDU. The McioInfo data structure provides the runtime information on the MCIOs obtained from the MCIO controller.\nNOTE: There are different types of MCIOs. The set of VNFC instances based on the same VDU is represented by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type \n of MCIO, e.g. a POD.\n\nRuntime information of the set of OS containers realizing an individual VNFC instance is not part of the McioInfo data structure; such runtime information is provided in the ResourceHandle data structure referenced from the VnfcResourceInfo. The McioInfo does not provide runtime information of a constituent VNFC instance created based on a specific VDU.\nNOTE 1: The type of MCIO as specified in the declarative descriptor of the MCIO, and that can be read from the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the \n “kind” property of the declarative descriptor.\nNOTE 2: If the attribute additionalInfo is present, it may contain runtime information on the actual and desired state of the MCIO(s). \nNOTE 3: When the container infrastructure service is a Kubernetes® instance, the mcioId is the combined values from the kind and name fields of the Kubernetes resource object, separated by a slash. \n Example: \"Deployment/abcd\". \nNOTE 4: When the container infrastructure service is a Kubernetes® instance, the mcioName is the name field of the resource object.\n","type":"object","required":["mcioId","mcioName","mcioNamespace","vduId","cismId","mcioType","desiredInstances","availableInstances"],"properties":{"mcioId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioName":{"description":"Human readable name of this MCIO. See note 4.\n","type":"string"},"mcioNamespace":{"description":"Namespace of this MCIO.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cismId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioType":{"description":"The type of MCIO. Specific values, their semantics and associated MCIO types are defined in clause 5.5.4.9. Additional values are also permitted. See note 1.\n","type":"string","enum":["Deployment","Statefulset","DaemonSet"]},"desiredInstances":{"description":"Number of desired MCIO instances.\n","type":"integer"},"availableInstances":{"description":"Number of available MCIO instances.\n","type":"integer"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this MCIO instance uses. Shall be present when using in delegation mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfPaasServiceInfo":{"description":"Information on the PaaS Services assigned and used by the VNF instance.\n","type":"array","items":{"description":"This type provides input information about a PaaS Service that is used by a VNF instance. The PaasServiceInfo is comprised of various sets of information. Some information comes from the VNFD, other information comes from the PaaS Service assets provided by the NFVO to the VNFM, and other information is provided at runtime information about the usage of the PaaS Service.\n","type":"object","required":["id","paasServiceId","paasServiceType","paasServiceRequestId","paasServiceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceType":{"description":"The type of PaaS Service. The value of this attribute is expected to be matched against values of the registered PaaS Services in the PSR.","type":"string"},"paasServiceVersion":{"description":"A version.\n","type":"string"},"paasServiceRequestId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"paasServiceHandle":{"description":"This type provides information enabling the access and use of the PaaS Service by the VNF instance. The type and format of the handle depends on the form that the PaaS Service is formed.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"indicators":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"instantiate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"terminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"heal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"operate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"createSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"revertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeCurrentVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"recentVnfLcmOperationLinks":{"description":"Links to the most recent LCM operation occurrences related to this resource. See note 9.\n","type":"object","properties":{"recentVnfLcmOperation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmInstantiation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmTerminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmHeal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmOperate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmModifyInfo":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmCreateSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmRevertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmSelectDplMods":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}},"vnfcSnapshots":{"description":"Information about VNFC snapshots constituting this VNF snapshot.\n","type":"array","items":{"description":"This type represents a VNFC snapshot.\nNOTE 1:\tThe identifier of the compute snapshot resource is assigned during creation of a VNFC snapshot \n being returned from the VIM as output data in the response message of the individual resource \n operations. This attribute shall only be present for a VNFC snapshot that has been newly created \n by the VNFM as a result of the \"Create VNF snapshot task\".\nNOTE 2:\tThe identifier of the storage snapshot resource is assigned during creation of a VNFC snapshot being \n returned from the VIM as output data in the response message of the individual resource operations. \n This attribute shall only be present for a VNFC snapshot with an associated storage resource and that \n has been newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n","type":"object","required":["id","vnfcInstanceId","triggeredAt","vnfcResourceId"],"properties":{"id":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"vnfcInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"creationStartedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"creationFinishedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfcResourceInfoId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"computeSnapshotResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"storageSnapshotResources":{"description":"Mapping of the storage resources associated to the VNFC with the storage snapshot resources.\n","type":"array","items":{"type":"object","required":["storageResourceId"],"properties":{"storageResourceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"storageSnapshotResource":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"vnfStateSnapshotInfo":{"description":"This type represents information about VNF-specific state snapshot data.\n","type":"object","required":["checksum","isEncrypted"],"properties":{"checksum":{"description":"Cheksum description\n","type":"string"},"isEncrypted":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfStateSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"takenFrom":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"VnfSnapshots.Get.200":{"description":"200 OK\n\nShall be returned when information about zero or more VNF snapshots was queried successfully.\nThe response body shall contain in an array the representations of zero or more\n\"Individual VNF snapshot\" resources, as defined in clause 5.5.2.22.\nIf the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013\nfor this resource, inclusion of the Link HTTP header in this response shall follow the provisions\nin clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents an \"Individual VNF snapshot\" resource.\n","type":"object","required":["id","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfSnapshotPkgId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfSnapshot":{"description":"This type represents a VNF snapshot.\n","type":"object","required":["id","vnfInstanceId","triggeredAt","vnfdId","vnfInfo","vnfcSnapshots"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"creationStartedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"creationFinishedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstance":{"description":"This type represents a VNF instance.\nNOTE:\tClause B.3.2 provides examples illustrating the relationship among the different run-time \n information elements (CP, VL and link ports) used to represent the connectivity of a VNF.\n\nNOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist between \n the previous and the newly referred VNF package, i.e. when the new VNFD is changed with \n respect to the previous VNFD in other aspects than merely referencing to other VNF software \n images. In order to avoid misalignment of the VnfInstance with the current VNF's on-boarded \n VNF Package, the values of attributes in the VnfInstance that have corresponding attributes \n in the VNFD shall be kept in sync with the values in the VNFD.\nNOTE 2:\tETSI GS NFV-SOL 001 [14] specifies the structure and format of the VNFD based on TOSCA specifications. NOTE 3:\tVNF configurable properties are sometimes also referred to as configuration parameters applicable \n to a VNF. Some of these are set prior to instantiation and cannot be modified if the VNF is instantiated, \n some are set prior to instantiation (are part of initial configuration) and can be modified later, \n and others can be set only after instantiation. The applicability of certain configuration may \n depend on the VNF and the required operation of the VNF at a certain point in time.\nNOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes \n of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared in the VNFD with a defined \n initial value. The defined initial values can be declared in the VNFD, and/or, in case of \"metadata\", \n obtained from the \"CreateVnfRequest\" structure. Child attributes of \"vnfConfigurableProperties\", \n \"metadata\" and \"extensions\" that have no defined initial value shall not be created, in order to be \n consistent with the semantics of the JSON Merge Patch method (see IETF RFC 7396) that interprets null \n values as deletion request.\nNOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a \n multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same \n VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed \n multi-site VL instance (refer to clause 5.5.3.3).\nNOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity, they shall \n not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\nNOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing \n the trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\nNOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the \n VNF LCM operation explicitly indicates the scale level for the aspect.\nNOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n","type":"object","required":["id","vnfdId","vnfProvider","vnfProductName","vnfSoftwareVersion","vnfdVersion","instantiationState","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceName":{"description":"Name of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfInstanceDescription":{"description":"Human-readable description of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"Provider of the VNF and the VNFD. The value is copied from the VNFD.\n","type":"string"},"vnfProductName":{"description":"Name to identify the VNF Product. The value is copied from the VNFD.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vimConnectionInfo":{"description":"Information about VIM or CISM connections to be used for managing the resources for the VNF instance. The keys of the map, each of which identifies information about a particular VIM connection, are managed by the NFVO and referenced from other data structures via the \"vimConnectionId\" attribute. This attribute shall only be supported and present if - the resources of at least of the VNFCs are managed by a VIM and VNF-related resource management in direct mode is applicable. - the resources of at least of the VNFCs are managed by a CISM. This attribute can be modified with the PATCH method. If VIM connection information is provisioned to the VNFM by means outside the scope of the present document, the information in the \"vimConnectionInfo\" attribute provides necessary information for binding the VnfInstance representing the \"Individual VNF instance\" to the applicable VIM connection information used to perform resource management for the VNF instance. See also the definition of the \"VimConnectionInfo\" in clause 4.4.1.6.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"cirConnectionInfo":{"description":"Information about the CIR connection for managing OS container images for the VNF instance. Shall be present when all or part of the VNF is realized by a set of OS containers and shall be absent otherwise.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mciopRepositoryInfo":{"description":"Information about the MCIOP repository for the VNF instance. Shall be present when all or part of the VNF is realized by a set of OS containers and shall be absent otherwise. See note 1.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"certificateInfo":{"description":"This type provides input information related to certificate and certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateConfigurationInfo":{"description":"This type provides input information related to certificate management.\n","type":"object","required":["securityPolicy"],"properties":{"certificateBaseProfile":{"description":"Information for certificate profile.","type":"array","items":{"description":"NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\nThis type provides input information to override certificate base profile for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"description":"Issuer of certificates. See note.","type":"string"},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to the subject of the certificate.\nNOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of the certification target subject FQDN. Can be set empty when this certificate is used for encrypted communication using IP address. See note.\n","type":"string"},"organization":{"description":"Information of the certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of the certification target subject Country. See note.","type":"string"},"state":{"description":"Information of the certification target subject State. See note.","type":"string"},"locality":{"description":"Information of the certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of the certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"description":"Basic constraints of certificates. See note.","type":"string"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [14], clause 7.1.19.4). See note.\n","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}}},"securityPolicy":{"description":"Information for security policy to be satisfied for certificate.","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"number"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"number"}}}},"delegationSupportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"cmfInfo":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["id","endPoint","supportedProtocol"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"endPoint":{"description":"End point of CMF instance.","type":"object","properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocol":{"description":"Supported protocols by CMF instance.","type":"array","items":{"description":"Supported protocol by CMF instance.","type":"string","enum":["CMP","CMPv2","EST","SCEP"]}},"certificateChain":{"description":"Certificate chain that this CMF provides.","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"certificateContents":{"description":"Information for contents of issued certificates. The information contained in this attribute may be updated over time during the VNF LCM, e.g., certificate(s) renewal.\n","type":"array","items":{"description":"This type provides input information related to certificate content.\nNOTE: The CertificateDesc data type is defined in clause 7.1.19.2 of ETSI GS NFV IFA 011 [10].\n","type":"object","required":["id","certificateDescId","certificateType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"certificateType":{"description":"Type of this certificate.","type":"string","enum":["VNFCI_CERT","VNFOAM_CERT"]},"supportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"version":{"description":"A version.\n","type":"string"},"serialNumber":{"description":"Serial number of this certificate.","type":"integer"},"signatureAlgorithm":{"description":"Algorithm of this certificate's signature.","type":"string"},"issuer":{"description":"Issuer of this certificate.","type":"string"},"notBefore":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"notAfter":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"subject":{"description":"Subject of this certificate.","type":"string"},"publicKeyAlgorithm":{"description":"Algorithm of this certificate's public key.","type":"string"},"publicKey":{"description":"Public key of this certificate.","type":"string"},"certificateExtensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"instantiationState":{"description":"The instantiation state of the VNF. Permitted values: - NOT_INSTANTIATED: The VNF instance is terminated or not instantiated. - INSTANTIATED: The VNF instance is instantiated.\n","type":"string","enum":["NOT_INSTANTIATED","INSTANTIATED"]},"instantiatedVnfInfo":{"description":"Information specific to an instantiated VNF instance. This attribute shall be present if the instantiateState attribute value is INSTANTIATED.\n","type":"object","required":["flavourId","vnfState"],"properties":{"flavourId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfState":{"description":"STARTED: The VNF instance is up and running. STOPPED: The VNF instance has been shut down.\n","type":"string","enum":["STARTED","STOPPED"]},"vnfPowerState":{"description":"This type represents information about the power state of a VNF instance.\n","type":"object","required":["powerProfileId","name"],"properties":{"powerProfileId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Name of the power profile as provided in the VNFD.\n","type":"string"},"powerConsumptionInfo":{"description":"This type represents information about estimated power consumption of the resources associated with the power profile, as provided in the VNFD.\n","type":"object","required":["minPowerConsumption","maxPowerConsumption","averagePowerConsumption"],"properties":{"minPowerConsumption":{"description":"Minimum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"maxPowerConsumption":{"description":"Maximum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"averagePowerConsumption":{"description":"Average power consumption of this power profile. Unit is KW/h.\n","type":"integer"}}}}},"scaleStatus":{"description":"Scale status of the VNF, one entry per aspect. Represents for every scaling aspect how \"big\" the VNF has been scaled w.r.t. that aspect.\nThis attribute shall be present if the VNF supports scaling. See clause B.2 for an explanation of VNF scaling.\nFor an aspect that has not been deployed because the related deployableModule has not been selected, it indicates the scale level that has been requested in the instantiation or in a scaling operation, or, if none has been requested in any of them, the scale level applicable to the aspect based on the default instantiation level. See note 8.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"maxScaleLevels":{"description":"Maximum allowed scale levels of the VNF, one entry per aspect. This attribute shall be present if the VNF supports scaling.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"selectedDeployableModule":{"description":"References a currently selected deployable module, as defined in the VNFD, that has already completed the instantiation of its VNFCs.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceCapacityDefinition":{"description":"Shows current values of VDU attributes related to resource capacity, if different to the default values from the VNFD, as indicated in the (one or more) request(s) of all completed VNF LCM operation(s) that contain this attribute. If an attribute value has been modified multiple times, only the last value is shown. The values indicated in this attribute are applicable to all VNFC instances based on the VDU to which the resourceCapacityDefinition is related.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes.\nThe tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request.\nAt most one tag can be included when the data type is used in a VNF LCM operation request.\nWhen the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.\n","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced.\n","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute 'type' indicates OSCONTAINER and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource. See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resource property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for this virtual compute descriptor. The value is a numberthat indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) that indicates the valid vaues for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"extCpInfo":{"description":"Information about the external CPs exposed by the VNF instance. When trunking is enabled, the list of entries includes both, external CPs corresponding to parent ports of a trunk, and external CPs associated to sub-ports of a trunk.See note 7.\n","type":"array","items":{"description":"This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n","type":"object","required":["id","cpdId","cpConfigId","cpProtocolInfo"],"oneOf":[{"required":["associatedVnfcCpId"]},{"required":["associatedVipCpId"]},{"required":["associatedVnfVirtualLinkId"]}],"properties":{"id":{"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"},"cpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extLinkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"associatedVnfcCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVipCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVirtualCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVnfVirtualLinkId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 3 and 4.\nIt shall be present if the external CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNF CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpSecurityGroupInfo":{"description":"This type provides the list of active security group rules applied to an external CP instance. The type identifies which \"SecurityGroupRule\" specified in the VNFD are activated and the values of its attributes.\n","type":"object","required":["securityGroupRuleId","etherType","protocol","portRangeMin","portRangeMax"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"description":{"description":"Human readable description of the security group rule.\n","type":"string"},"etherType":{"description":"Indicates the protocol carried over the Ethernet layer. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"protocol":{"description":"Indicates the protocol carried over the IP layer. Permitted values: any protocol defined in the IANA protocol registry (refer to clause 9.10.1.2 ofd ETSI GS NFV-SOL 001 for further information).\n","type":"string"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule.\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule.\n","type":"integer"}}}}}},"vipCpInfo":{"description":"VIP CPs that are part of the VNF instance. Shall be present when that particular VIP CP of the VNFC instance is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","minItems":1,"items":{"description":"This type provides information related to virtual IP (VIP) CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["cpInstanceId","cpdId"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for layer 3. There may be one cpProtocolInfo for layer 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"associatedVnfcCpIds":{"description":"Identifiers of the VnfcCps that share the virtual IP address allocated to the VIP CP instance. See note.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualCpInfo":{"description":"Virtual CPs that are part of the VNF instance. Shall be present when a particular Virtual CP is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","items":{"description":"This type provides information related to a virtual CP instance of a VNF.\nNOTE 1: A consumer of the VNF LCM interface can learn the actual VNFC instances implementing the service accessible via the virtual CP instance by querying the \"vnfcResourceInfo\" from the \"InstantiatedVnfInfo\" \n and filtering by corresponding \"vduIds\" values.\nNOTE 2: The information can be omitted because it is already available as part of the external CP information in the VnfExtCpInfo structure.\n","type":"object","required":["cpInstanceId","cpdId","resourceHandle","vduIds"],"properties":{"cpInstanceId":{"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"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for each layer protocol supported. This attribute may be omitted if the virtual CP is exposed as an external CP. See note 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vduIds":{"description":"Reference to the VDU(s) which implement the service accessible via the virtual CP instance. See note 1.\n","type":"array","minItems":1,"items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"additionalServiceInfo":{"description":"Additional service identification information of the virtual CP instance.\n","type":"array","items":{"description":"This type provides additional service information of the virtual CP instance used to expose properties of the virtual CP to NFV-MANO.\nNOTE: This attribute shall only be present if additional information is needed to identify the service termination within the VNF, such as for example a URL path information in an HTTP request required \n to allow a single virtual CP IP address to be used for several HTTP based services that use the \n same port number.\n","type":"object","required":["portInfo"],"properties":{"portInfo":{"description":"Service port numbers exposed by the virtual CP instance.\n","minItems":1,"type":"array","items":{"description":"This type describes the service identifying port properties exposed by the virtual CP instance.\n","type":"object","required":["name","port","portConfigurable"],"properties":{"name":{"description":"The name of the port exposed by the virtual CP instance.\n","type":"string"},"protocol":{"description":"The L4 protocol for this port exposed by the virtual CP instance.\nPermitted values: - TCP - UDP - SCTP\n","type":"string","enum":["TCP","UDP","SCTP"]},"port":{"description":"The L4 port number exposed by the virtual CP instance.\n","type":"integer"},"portConfigurable":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"}}}},"serviceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"extVirtualLinkInfo":{"description":"Information about the external VLs the VNF instance is connected to.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extManagedVirtualLinkInfo":{"description":"Information about the externally-managed internal VLs of the VNF instance. See notes 5 and 6.\n","type":"array","items":{"description":"This type provides information about an externally-managed virtual link. Note: Both \"vnfLinkPort\" and \"vnfNetAttDefResource\" attributes can be present in an \"ExtManagedVirtualLinkInfo\" to indicate that a single internal virtual link is providing connectivity for both VM-based and container-based \n VNFCs.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPorts":{"description":"Link ports of this VL. See note.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"vnfNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL. See note.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"extManagedMultisiteVirtualLinkId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"routingResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"monitoringParameters":{"description":"Active monitoring parameters.\n","type":"array","items":{"description":"This type represents a monitoring parameter that is tracked by the VNFM,\n","type":"object","required":["id","performanceMetric"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human readable name of the monitoring parameter, as defined in the VNFD.\n","type":"string"},"performanceMetric":{"description":"Performance metric that is monitored. This attribute shall contain the related \"Measurement Name\" value as defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"}}}},"localizationLanguage":{"description":"Information about localization language of the VNF (includes e.g. strings in the VNFD). The localization languages supported by a VNF can be declared in the VNFD, and localization language selection can take place at instantiation time. The value shall comply with the format defined in IETF RFC 5646.\n","type":"string"},"vnfcResourceInfo":{"description":"Information about the virtualised compute and storage resources used by the VNFCs of the VNF instance.\n","type":"array","items":{"description":"This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure of\n information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n a) For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n b) For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\nNOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on \n TOSCA specifications.\nNOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an \n internal VL that exposes an external CP. A VNFC CP is \"exposed as\" an external \n CP if it is connected directly to an external VL.\nNOTE 3:\tThe information can be omitted because it is already available as part of the \n external CP information.\nNOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\"\n structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVnfc\" structure in the VNF LCM operation occurrence notifications\n or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\nNOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment\n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. \nNOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n","type":"object","required":["id","vduId","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResourceIds":{"description":"References to the VirtualStorage resources or references to Storage MCIOs. The value refers to a VirtualStorageResourceInfo item in the VnfInstance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcCpInfo":{"description":"CPs of the VNFC instance. Shall be present when that particular CP of the VNFC instance is exposed as an external CP of the VNF instance or is connected to an external CP of the VNF instance. See note 2. May be present otherwise. See note 7.\n","type":"array","items":{"type":"object","required":["id","cpdId"],"properties":{"id":{"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"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP. May be omitted if the VNFC CP is exposed as an external CP. See note 3.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"parentCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 5 and 6. It shall be present if the internal CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfVirtualLinkResourceInfo":{"description":"Information about the virtualised network resources used by the VLs of the VNF instance. See note 6.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by an internal VL instance in a VNF instance.\nNote: If only the value or the presence of this attribute is changed in the \"VnfVirtualLinkResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including\n a related \"AffectedVirtualLink\" structure in the VNF LCM operation occurrence notifications or the\n \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLinkPorts":{"description":"Links ports of this VL. Shall be present when the linkPort is used for external connectivity by the VNF (refer to VnfLinkPortInfo). May be present otherwise.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualStorageResourceInfo":{"description":"Information on the virtualised storage resource(s) used as storage for the VNF instance.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance.\nNote: If only the value or the presence of this attribute is changed in the \"VirtualStorageResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVirtualStorage\" structure in the VNF LCM operation occurrence\n notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","virtualStorageDescId","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mcioInfo":{"description":"Information on the MCIO(s) representing VNFC instance(s) realized by one or a set of OS containers and created from the same VDU for the VNF instance.\n","type":"array","items":{"description":"This type provides information about an MCIO representing the set of VNFC instances realized by one or a set of OS containers which have been created based on the same VDU. Within the CISM, an MCIO controller monitors the actual state of an MCIO representing the set of VNFC instances realized by one or a set of OS containers and compare it to the desired state For an MCIO related to a VDU that has the attribute isNumOfInstancesClusterBased set to FALSE the desired state is specified in the respective declarative descriptor. For an MCIO related to a VDU that has the attribute isNumOfInstancesClusterBased set to TRUE, the desired state is determined by the number of CIS-nodes in the cluster that fulfil the VDU requirements.as specified in the respective declarative descriptor. It triggers actions toward the CIS to align the actual to the desired state. Monitoring the actual state includes monitoring the number of MCIO instances available at any specific point in time. In addition, an MCIO controller maintains properties and runtime information on the MCIO instances which have been created based on the same VDU. The McioInfo data structure provides the runtime information on the MCIOs obtained from the MCIO controller.\nNOTE: There are different types of MCIOs. The set of VNFC instances based on the same VDU is represented by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type \n of MCIO, e.g. a POD.\n\nRuntime information of the set of OS containers realizing an individual VNFC instance is not part of the McioInfo data structure; such runtime information is provided in the ResourceHandle data structure referenced from the VnfcResourceInfo. The McioInfo does not provide runtime information of a constituent VNFC instance created based on a specific VDU.\nNOTE 1: The type of MCIO as specified in the declarative descriptor of the MCIO, and that can be read from the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the \n “kind” property of the declarative descriptor.\nNOTE 2: If the attribute additionalInfo is present, it may contain runtime information on the actual and desired state of the MCIO(s). \nNOTE 3: When the container infrastructure service is a Kubernetes® instance, the mcioId is the combined values from the kind and name fields of the Kubernetes resource object, separated by a slash. \n Example: \"Deployment/abcd\". \nNOTE 4: When the container infrastructure service is a Kubernetes® instance, the mcioName is the name field of the resource object.\n","type":"object","required":["mcioId","mcioName","mcioNamespace","vduId","cismId","mcioType","desiredInstances","availableInstances"],"properties":{"mcioId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioName":{"description":"Human readable name of this MCIO. See note 4.\n","type":"string"},"mcioNamespace":{"description":"Namespace of this MCIO.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cismId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioType":{"description":"The type of MCIO. Specific values, their semantics and associated MCIO types are defined in clause 5.5.4.9. Additional values are also permitted. See note 1.\n","type":"string","enum":["Deployment","Statefulset","DaemonSet"]},"desiredInstances":{"description":"Number of desired MCIO instances.\n","type":"integer"},"availableInstances":{"description":"Number of available MCIO instances.\n","type":"integer"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this MCIO instance uses. Shall be present when using in delegation mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfPaasServiceInfo":{"description":"Information on the PaaS Services assigned and used by the VNF instance.\n","type":"array","items":{"description":"This type provides input information about a PaaS Service that is used by a VNF instance. The PaasServiceInfo is comprised of various sets of information. Some information comes from the VNFD, other information comes from the PaaS Service assets provided by the NFVO to the VNFM, and other information is provided at runtime information about the usage of the PaaS Service.\n","type":"object","required":["id","paasServiceId","paasServiceType","paasServiceRequestId","paasServiceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceType":{"description":"The type of PaaS Service. The value of this attribute is expected to be matched against values of the registered PaaS Services in the PSR.","type":"string"},"paasServiceVersion":{"description":"A version.\n","type":"string"},"paasServiceRequestId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"paasServiceHandle":{"description":"This type provides information enabling the access and use of the PaaS Service by the VNF instance. The type and format of the handle depends on the form that the PaaS Service is formed.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"indicators":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"instantiate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"terminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"heal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"operate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"createSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"revertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeCurrentVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"recentVnfLcmOperationLinks":{"description":"Links to the most recent LCM operation occurrences related to this resource. See note 9.\n","type":"object","properties":{"recentVnfLcmOperation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmInstantiation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmTerminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmHeal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmOperate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmModifyInfo":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmCreateSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmRevertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmSelectDplMods":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}},"vnfcSnapshots":{"description":"Information about VNFC snapshots constituting this VNF snapshot.\n","type":"array","items":{"description":"This type represents a VNFC snapshot.\nNOTE 1:\tThe identifier of the compute snapshot resource is assigned during creation of a VNFC snapshot \n being returned from the VIM as output data in the response message of the individual resource \n operations. This attribute shall only be present for a VNFC snapshot that has been newly created \n by the VNFM as a result of the \"Create VNF snapshot task\".\nNOTE 2:\tThe identifier of the storage snapshot resource is assigned during creation of a VNFC snapshot being \n returned from the VIM as output data in the response message of the individual resource operations. \n This attribute shall only be present for a VNFC snapshot with an associated storage resource and that \n has been newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n","type":"object","required":["id","vnfcInstanceId","triggeredAt","vnfcResourceId"],"properties":{"id":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"vnfcInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"creationStartedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"creationFinishedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfcResourceInfoId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"computeSnapshotResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"storageSnapshotResources":{"description":"Mapping of the storage resources associated to the VNFC with the storage snapshot resources.\n","type":"array","items":{"type":"object","required":["storageResourceId"],"properties":{"storageResourceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"storageSnapshotResource":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"vnfStateSnapshotInfo":{"description":"This type represents information about VNF-specific state snapshot data.\n","type":"object","required":["checksum","isEncrypted"],"properties":{"checksum":{"description":"Cheksum description\n","type":"string"},"isEncrypted":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfStateSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"takenFrom":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"IndividualVnfSnapshot.Get.200":{"description":"200 OK\n\nShall be returned when information about an individual VNF snapshot was read successfully.\nThe response body shall contain a representation of the \"Individual VNF snapshot\" resource,\nas defined in clause 5.5.2.22.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"ETag":{"description":"Used to provide the current entity-tag for the selected resource representation. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string"}},"Last-Modified":{"description":"Used to provide a timestamp indicating the date and time at which the server believes the selected resource representation was last modified. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string","format":"date-time"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents an \"Individual VNF snapshot\" resource.\n","type":"object","required":["id","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfSnapshotPkgId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfSnapshot":{"description":"This type represents a VNF snapshot.\n","type":"object","required":["id","vnfInstanceId","triggeredAt","vnfdId","vnfInfo","vnfcSnapshots"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"creationStartedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"creationFinishedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstance":{"description":"This type represents a VNF instance.\nNOTE:\tClause B.3.2 provides examples illustrating the relationship among the different run-time \n information elements (CP, VL and link ports) used to represent the connectivity of a VNF.\n\nNOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist between \n the previous and the newly referred VNF package, i.e. when the new VNFD is changed with \n respect to the previous VNFD in other aspects than merely referencing to other VNF software \n images. In order to avoid misalignment of the VnfInstance with the current VNF's on-boarded \n VNF Package, the values of attributes in the VnfInstance that have corresponding attributes \n in the VNFD shall be kept in sync with the values in the VNFD.\nNOTE 2:\tETSI GS NFV-SOL 001 [14] specifies the structure and format of the VNFD based on TOSCA specifications. NOTE 3:\tVNF configurable properties are sometimes also referred to as configuration parameters applicable \n to a VNF. Some of these are set prior to instantiation and cannot be modified if the VNF is instantiated, \n some are set prior to instantiation (are part of initial configuration) and can be modified later, \n and others can be set only after instantiation. The applicability of certain configuration may \n depend on the VNF and the required operation of the VNF at a certain point in time.\nNOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes \n of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared in the VNFD with a defined \n initial value. The defined initial values can be declared in the VNFD, and/or, in case of \"metadata\", \n obtained from the \"CreateVnfRequest\" structure. Child attributes of \"vnfConfigurableProperties\", \n \"metadata\" and \"extensions\" that have no defined initial value shall not be created, in order to be \n consistent with the semantics of the JSON Merge Patch method (see IETF RFC 7396) that interprets null \n values as deletion request.\nNOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a \n multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same \n VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed \n multi-site VL instance (refer to clause 5.5.3.3).\nNOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity, they shall \n not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\nNOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing \n the trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\nNOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the \n VNF LCM operation explicitly indicates the scale level for the aspect.\nNOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n","type":"object","required":["id","vnfdId","vnfProvider","vnfProductName","vnfSoftwareVersion","vnfdVersion","instantiationState","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceName":{"description":"Name of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfInstanceDescription":{"description":"Human-readable description of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"Provider of the VNF and the VNFD. The value is copied from the VNFD.\n","type":"string"},"vnfProductName":{"description":"Name to identify the VNF Product. The value is copied from the VNFD.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vimConnectionInfo":{"description":"Information about VIM or CISM connections to be used for managing the resources for the VNF instance. The keys of the map, each of which identifies information about a particular VIM connection, are managed by the NFVO and referenced from other data structures via the \"vimConnectionId\" attribute. This attribute shall only be supported and present if - the resources of at least of the VNFCs are managed by a VIM and VNF-related resource management in direct mode is applicable. - the resources of at least of the VNFCs are managed by a CISM. This attribute can be modified with the PATCH method. If VIM connection information is provisioned to the VNFM by means outside the scope of the present document, the information in the \"vimConnectionInfo\" attribute provides necessary information for binding the VnfInstance representing the \"Individual VNF instance\" to the applicable VIM connection information used to perform resource management for the VNF instance. See also the definition of the \"VimConnectionInfo\" in clause 4.4.1.6.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"cirConnectionInfo":{"description":"Information about the CIR connection for managing OS container images for the VNF instance. Shall be present when all or part of the VNF is realized by a set of OS containers and shall be absent otherwise.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mciopRepositoryInfo":{"description":"Information about the MCIOP repository for the VNF instance. Shall be present when all or part of the VNF is realized by a set of OS containers and shall be absent otherwise. See note 1.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"certificateInfo":{"description":"This type provides input information related to certificate and certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateConfigurationInfo":{"description":"This type provides input information related to certificate management.\n","type":"object","required":["securityPolicy"],"properties":{"certificateBaseProfile":{"description":"Information for certificate profile.","type":"array","items":{"description":"NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\nThis type provides input information to override certificate base profile for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"description":"Issuer of certificates. See note.","type":"string"},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to the subject of the certificate.\nNOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of the certification target subject FQDN. Can be set empty when this certificate is used for encrypted communication using IP address. See note.\n","type":"string"},"organization":{"description":"Information of the certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of the certification target subject Country. See note.","type":"string"},"state":{"description":"Information of the certification target subject State. See note.","type":"string"},"locality":{"description":"Information of the certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of the certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"description":"Basic constraints of certificates. See note.","type":"string"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [14], clause 7.1.19.4). See note.\n","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}}},"securityPolicy":{"description":"Information for security policy to be satisfied for certificate.","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"number"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"number"}}}},"delegationSupportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"cmfInfo":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["id","endPoint","supportedProtocol"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"endPoint":{"description":"End point of CMF instance.","type":"object","properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocol":{"description":"Supported protocols by CMF instance.","type":"array","items":{"description":"Supported protocol by CMF instance.","type":"string","enum":["CMP","CMPv2","EST","SCEP"]}},"certificateChain":{"description":"Certificate chain that this CMF provides.","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"certificateContents":{"description":"Information for contents of issued certificates. The information contained in this attribute may be updated over time during the VNF LCM, e.g., certificate(s) renewal.\n","type":"array","items":{"description":"This type provides input information related to certificate content.\nNOTE: The CertificateDesc data type is defined in clause 7.1.19.2 of ETSI GS NFV IFA 011 [10].\n","type":"object","required":["id","certificateDescId","certificateType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"certificateType":{"description":"Type of this certificate.","type":"string","enum":["VNFCI_CERT","VNFOAM_CERT"]},"supportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"version":{"description":"A version.\n","type":"string"},"serialNumber":{"description":"Serial number of this certificate.","type":"integer"},"signatureAlgorithm":{"description":"Algorithm of this certificate's signature.","type":"string"},"issuer":{"description":"Issuer of this certificate.","type":"string"},"notBefore":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"notAfter":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"subject":{"description":"Subject of this certificate.","type":"string"},"publicKeyAlgorithm":{"description":"Algorithm of this certificate's public key.","type":"string"},"publicKey":{"description":"Public key of this certificate.","type":"string"},"certificateExtensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"instantiationState":{"description":"The instantiation state of the VNF. Permitted values: - NOT_INSTANTIATED: The VNF instance is terminated or not instantiated. - INSTANTIATED: The VNF instance is instantiated.\n","type":"string","enum":["NOT_INSTANTIATED","INSTANTIATED"]},"instantiatedVnfInfo":{"description":"Information specific to an instantiated VNF instance. This attribute shall be present if the instantiateState attribute value is INSTANTIATED.\n","type":"object","required":["flavourId","vnfState"],"properties":{"flavourId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfState":{"description":"STARTED: The VNF instance is up and running. STOPPED: The VNF instance has been shut down.\n","type":"string","enum":["STARTED","STOPPED"]},"vnfPowerState":{"description":"This type represents information about the power state of a VNF instance.\n","type":"object","required":["powerProfileId","name"],"properties":{"powerProfileId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Name of the power profile as provided in the VNFD.\n","type":"string"},"powerConsumptionInfo":{"description":"This type represents information about estimated power consumption of the resources associated with the power profile, as provided in the VNFD.\n","type":"object","required":["minPowerConsumption","maxPowerConsumption","averagePowerConsumption"],"properties":{"minPowerConsumption":{"description":"Minimum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"maxPowerConsumption":{"description":"Maximum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"averagePowerConsumption":{"description":"Average power consumption of this power profile. Unit is KW/h.\n","type":"integer"}}}}},"scaleStatus":{"description":"Scale status of the VNF, one entry per aspect. Represents for every scaling aspect how \"big\" the VNF has been scaled w.r.t. that aspect.\nThis attribute shall be present if the VNF supports scaling. See clause B.2 for an explanation of VNF scaling.\nFor an aspect that has not been deployed because the related deployableModule has not been selected, it indicates the scale level that has been requested in the instantiation or in a scaling operation, or, if none has been requested in any of them, the scale level applicable to the aspect based on the default instantiation level. See note 8.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"maxScaleLevels":{"description":"Maximum allowed scale levels of the VNF, one entry per aspect. This attribute shall be present if the VNF supports scaling.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"selectedDeployableModule":{"description":"References a currently selected deployable module, as defined in the VNFD, that has already completed the instantiation of its VNFCs.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceCapacityDefinition":{"description":"Shows current values of VDU attributes related to resource capacity, if different to the default values from the VNFD, as indicated in the (one or more) request(s) of all completed VNF LCM operation(s) that contain this attribute. If an attribute value has been modified multiple times, only the last value is shown. The values indicated in this attribute are applicable to all VNFC instances based on the VDU to which the resourceCapacityDefinition is related.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes.\nThe tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request.\nAt most one tag can be included when the data type is used in a VNF LCM operation request.\nWhen the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.\n","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced.\n","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute 'type' indicates OSCONTAINER and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource. See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resource property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for this virtual compute descriptor. The value is a numberthat indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) that indicates the valid vaues for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"extCpInfo":{"description":"Information about the external CPs exposed by the VNF instance. When trunking is enabled, the list of entries includes both, external CPs corresponding to parent ports of a trunk, and external CPs associated to sub-ports of a trunk.See note 7.\n","type":"array","items":{"description":"This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n","type":"object","required":["id","cpdId","cpConfigId","cpProtocolInfo"],"oneOf":[{"required":["associatedVnfcCpId"]},{"required":["associatedVipCpId"]},{"required":["associatedVnfVirtualLinkId"]}],"properties":{"id":{"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"},"cpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extLinkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"associatedVnfcCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVipCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVirtualCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVnfVirtualLinkId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 3 and 4.\nIt shall be present if the external CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNF CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpSecurityGroupInfo":{"description":"This type provides the list of active security group rules applied to an external CP instance. The type identifies which \"SecurityGroupRule\" specified in the VNFD are activated and the values of its attributes.\n","type":"object","required":["securityGroupRuleId","etherType","protocol","portRangeMin","portRangeMax"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"description":{"description":"Human readable description of the security group rule.\n","type":"string"},"etherType":{"description":"Indicates the protocol carried over the Ethernet layer. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"protocol":{"description":"Indicates the protocol carried over the IP layer. Permitted values: any protocol defined in the IANA protocol registry (refer to clause 9.10.1.2 ofd ETSI GS NFV-SOL 001 for further information).\n","type":"string"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule.\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule.\n","type":"integer"}}}}}},"vipCpInfo":{"description":"VIP CPs that are part of the VNF instance. Shall be present when that particular VIP CP of the VNFC instance is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","minItems":1,"items":{"description":"This type provides information related to virtual IP (VIP) CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["cpInstanceId","cpdId"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for layer 3. There may be one cpProtocolInfo for layer 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"associatedVnfcCpIds":{"description":"Identifiers of the VnfcCps that share the virtual IP address allocated to the VIP CP instance. See note.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualCpInfo":{"description":"Virtual CPs that are part of the VNF instance. Shall be present when a particular Virtual CP is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","items":{"description":"This type provides information related to a virtual CP instance of a VNF.\nNOTE 1: A consumer of the VNF LCM interface can learn the actual VNFC instances implementing the service accessible via the virtual CP instance by querying the \"vnfcResourceInfo\" from the \"InstantiatedVnfInfo\" \n and filtering by corresponding \"vduIds\" values.\nNOTE 2: The information can be omitted because it is already available as part of the external CP information in the VnfExtCpInfo structure.\n","type":"object","required":["cpInstanceId","cpdId","resourceHandle","vduIds"],"properties":{"cpInstanceId":{"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"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for each layer protocol supported. This attribute may be omitted if the virtual CP is exposed as an external CP. See note 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vduIds":{"description":"Reference to the VDU(s) which implement the service accessible via the virtual CP instance. See note 1.\n","type":"array","minItems":1,"items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"additionalServiceInfo":{"description":"Additional service identification information of the virtual CP instance.\n","type":"array","items":{"description":"This type provides additional service information of the virtual CP instance used to expose properties of the virtual CP to NFV-MANO.\nNOTE: This attribute shall only be present if additional information is needed to identify the service termination within the VNF, such as for example a URL path information in an HTTP request required \n to allow a single virtual CP IP address to be used for several HTTP based services that use the \n same port number.\n","type":"object","required":["portInfo"],"properties":{"portInfo":{"description":"Service port numbers exposed by the virtual CP instance.\n","minItems":1,"type":"array","items":{"description":"This type describes the service identifying port properties exposed by the virtual CP instance.\n","type":"object","required":["name","port","portConfigurable"],"properties":{"name":{"description":"The name of the port exposed by the virtual CP instance.\n","type":"string"},"protocol":{"description":"The L4 protocol for this port exposed by the virtual CP instance.\nPermitted values: - TCP - UDP - SCTP\n","type":"string","enum":["TCP","UDP","SCTP"]},"port":{"description":"The L4 port number exposed by the virtual CP instance.\n","type":"integer"},"portConfigurable":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"}}}},"serviceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"extVirtualLinkInfo":{"description":"Information about the external VLs the VNF instance is connected to.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extManagedVirtualLinkInfo":{"description":"Information about the externally-managed internal VLs of the VNF instance. See notes 5 and 6.\n","type":"array","items":{"description":"This type provides information about an externally-managed virtual link. Note: Both \"vnfLinkPort\" and \"vnfNetAttDefResource\" attributes can be present in an \"ExtManagedVirtualLinkInfo\" to indicate that a single internal virtual link is providing connectivity for both VM-based and container-based \n VNFCs.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPorts":{"description":"Link ports of this VL. See note.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"vnfNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL. See note.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"extManagedMultisiteVirtualLinkId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"routingResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"monitoringParameters":{"description":"Active monitoring parameters.\n","type":"array","items":{"description":"This type represents a monitoring parameter that is tracked by the VNFM,\n","type":"object","required":["id","performanceMetric"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human readable name of the monitoring parameter, as defined in the VNFD.\n","type":"string"},"performanceMetric":{"description":"Performance metric that is monitored. This attribute shall contain the related \"Measurement Name\" value as defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"}}}},"localizationLanguage":{"description":"Information about localization language of the VNF (includes e.g. strings in the VNFD). The localization languages supported by a VNF can be declared in the VNFD, and localization language selection can take place at instantiation time. The value shall comply with the format defined in IETF RFC 5646.\n","type":"string"},"vnfcResourceInfo":{"description":"Information about the virtualised compute and storage resources used by the VNFCs of the VNF instance.\n","type":"array","items":{"description":"This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure of\n information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n a) For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n b) For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\nNOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on \n TOSCA specifications.\nNOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an \n internal VL that exposes an external CP. A VNFC CP is \"exposed as\" an external \n CP if it is connected directly to an external VL.\nNOTE 3:\tThe information can be omitted because it is already available as part of the \n external CP information.\nNOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\"\n structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVnfc\" structure in the VNF LCM operation occurrence notifications\n or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\nNOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment\n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. \nNOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n","type":"object","required":["id","vduId","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResourceIds":{"description":"References to the VirtualStorage resources or references to Storage MCIOs. The value refers to a VirtualStorageResourceInfo item in the VnfInstance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcCpInfo":{"description":"CPs of the VNFC instance. Shall be present when that particular CP of the VNFC instance is exposed as an external CP of the VNF instance or is connected to an external CP of the VNF instance. See note 2. May be present otherwise. See note 7.\n","type":"array","items":{"type":"object","required":["id","cpdId"],"properties":{"id":{"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"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP. May be omitted if the VNFC CP is exposed as an external CP. See note 3.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"parentCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 5 and 6. It shall be present if the internal CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfVirtualLinkResourceInfo":{"description":"Information about the virtualised network resources used by the VLs of the VNF instance. See note 6.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by an internal VL instance in a VNF instance.\nNote: If only the value or the presence of this attribute is changed in the \"VnfVirtualLinkResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including\n a related \"AffectedVirtualLink\" structure in the VNF LCM operation occurrence notifications or the\n \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLinkPorts":{"description":"Links ports of this VL. Shall be present when the linkPort is used for external connectivity by the VNF (refer to VnfLinkPortInfo). May be present otherwise.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualStorageResourceInfo":{"description":"Information on the virtualised storage resource(s) used as storage for the VNF instance.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance.\nNote: If only the value or the presence of this attribute is changed in the \"VirtualStorageResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVirtualStorage\" structure in the VNF LCM operation occurrence\n notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","virtualStorageDescId","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mcioInfo":{"description":"Information on the MCIO(s) representing VNFC instance(s) realized by one or a set of OS containers and created from the same VDU for the VNF instance.\n","type":"array","items":{"description":"This type provides information about an MCIO representing the set of VNFC instances realized by one or a set of OS containers which have been created based on the same VDU. Within the CISM, an MCIO controller monitors the actual state of an MCIO representing the set of VNFC instances realized by one or a set of OS containers and compare it to the desired state For an MCIO related to a VDU that has the attribute isNumOfInstancesClusterBased set to FALSE the desired state is specified in the respective declarative descriptor. For an MCIO related to a VDU that has the attribute isNumOfInstancesClusterBased set to TRUE, the desired state is determined by the number of CIS-nodes in the cluster that fulfil the VDU requirements.as specified in the respective declarative descriptor. It triggers actions toward the CIS to align the actual to the desired state. Monitoring the actual state includes monitoring the number of MCIO instances available at any specific point in time. In addition, an MCIO controller maintains properties and runtime information on the MCIO instances which have been created based on the same VDU. The McioInfo data structure provides the runtime information on the MCIOs obtained from the MCIO controller.\nNOTE: There are different types of MCIOs. The set of VNFC instances based on the same VDU is represented by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type \n of MCIO, e.g. a POD.\n\nRuntime information of the set of OS containers realizing an individual VNFC instance is not part of the McioInfo data structure; such runtime information is provided in the ResourceHandle data structure referenced from the VnfcResourceInfo. The McioInfo does not provide runtime information of a constituent VNFC instance created based on a specific VDU.\nNOTE 1: The type of MCIO as specified in the declarative descriptor of the MCIO, and that can be read from the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the \n “kind” property of the declarative descriptor.\nNOTE 2: If the attribute additionalInfo is present, it may contain runtime information on the actual and desired state of the MCIO(s). \nNOTE 3: When the container infrastructure service is a Kubernetes® instance, the mcioId is the combined values from the kind and name fields of the Kubernetes resource object, separated by a slash. \n Example: \"Deployment/abcd\". \nNOTE 4: When the container infrastructure service is a Kubernetes® instance, the mcioName is the name field of the resource object.\n","type":"object","required":["mcioId","mcioName","mcioNamespace","vduId","cismId","mcioType","desiredInstances","availableInstances"],"properties":{"mcioId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioName":{"description":"Human readable name of this MCIO. See note 4.\n","type":"string"},"mcioNamespace":{"description":"Namespace of this MCIO.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cismId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioType":{"description":"The type of MCIO. Specific values, their semantics and associated MCIO types are defined in clause 5.5.4.9. Additional values are also permitted. See note 1.\n","type":"string","enum":["Deployment","Statefulset","DaemonSet"]},"desiredInstances":{"description":"Number of desired MCIO instances.\n","type":"integer"},"availableInstances":{"description":"Number of available MCIO instances.\n","type":"integer"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this MCIO instance uses. Shall be present when using in delegation mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfPaasServiceInfo":{"description":"Information on the PaaS Services assigned and used by the VNF instance.\n","type":"array","items":{"description":"This type provides input information about a PaaS Service that is used by a VNF instance. The PaasServiceInfo is comprised of various sets of information. Some information comes from the VNFD, other information comes from the PaaS Service assets provided by the NFVO to the VNFM, and other information is provided at runtime information about the usage of the PaaS Service.\n","type":"object","required":["id","paasServiceId","paasServiceType","paasServiceRequestId","paasServiceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceType":{"description":"The type of PaaS Service. The value of this attribute is expected to be matched against values of the registered PaaS Services in the PSR.","type":"string"},"paasServiceVersion":{"description":"A version.\n","type":"string"},"paasServiceRequestId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"paasServiceHandle":{"description":"This type provides information enabling the access and use of the PaaS Service by the VNF instance. The type and format of the handle depends on the form that the PaaS Service is formed.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"indicators":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"instantiate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"terminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"heal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"operate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"createSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"revertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeCurrentVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"recentVnfLcmOperationLinks":{"description":"Links to the most recent LCM operation occurrences related to this resource. See note 9.\n","type":"object","properties":{"recentVnfLcmOperation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmInstantiation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmTerminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmHeal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmOperate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmModifyInfo":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmCreateSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmRevertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmSelectDplMods":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}},"vnfcSnapshots":{"description":"Information about VNFC snapshots constituting this VNF snapshot.\n","type":"array","items":{"description":"This type represents a VNFC snapshot.\nNOTE 1:\tThe identifier of the compute snapshot resource is assigned during creation of a VNFC snapshot \n being returned from the VIM as output data in the response message of the individual resource \n operations. This attribute shall only be present for a VNFC snapshot that has been newly created \n by the VNFM as a result of the \"Create VNF snapshot task\".\nNOTE 2:\tThe identifier of the storage snapshot resource is assigned during creation of a VNFC snapshot being \n returned from the VIM as output data in the response message of the individual resource operations. \n This attribute shall only be present for a VNFC snapshot with an associated storage resource and that \n has been newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n","type":"object","required":["id","vnfcInstanceId","triggeredAt","vnfcResourceId"],"properties":{"id":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"vnfcInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"creationStartedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"creationFinishedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfcResourceInfoId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"computeSnapshotResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"storageSnapshotResources":{"description":"Mapping of the storage resources associated to the VNFC with the storage snapshot resources.\n","type":"array","items":{"type":"object","required":["storageResourceId"],"properties":{"storageResourceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"storageSnapshotResource":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"vnfStateSnapshotInfo":{"description":"This type represents information about VNF-specific state snapshot data.\n","type":"object","required":["checksum","isEncrypted"],"properties":{"checksum":{"description":"Cheksum description\n","type":"string"},"isEncrypted":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfStateSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"takenFrom":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"IndividualVnfSnapshot.Patch.200":{"description":"200 OK\n\nShall be returned when the modification of VNF snapshot information has been accepted and completed.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"ETag":{"description":"Used to provide the current entity-tag for the selected resource representation. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string"}},"Last-Modified":{"description":"Used to provide a timestamp indicating the date and time at which the server believes the selected resource representation was last modified. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string","format":"date-time"}}},"content":{"application/json":{"schema":{"description":"This type represents attribute modifications that were performed on an \"Individual VNF snapshot\"\nresource. The attributes that can be included consist of those requested to be modified explicitly\nin the \"VnfSnapshotInfoModificationRequest\" data structure, and additional attributes of the\n\"VnfSnapshotInfo\" data structure that were modified implicitly.\n","type":"object","properties":{"vnfSnapshotPkgId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfSnapshot":{"description":"This type represents a VNF snapshot.\n","type":"object","required":["id","vnfInstanceId","triggeredAt","vnfdId","vnfInfo","vnfcSnapshots"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"creationStartedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"creationFinishedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstance":{"description":"This type represents a VNF instance.\nNOTE:\tClause B.3.2 provides examples illustrating the relationship among the different run-time \n information elements (CP, VL and link ports) used to represent the connectivity of a VNF.\n\nNOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist between \n the previous and the newly referred VNF package, i.e. when the new VNFD is changed with \n respect to the previous VNFD in other aspects than merely referencing to other VNF software \n images. In order to avoid misalignment of the VnfInstance with the current VNF's on-boarded \n VNF Package, the values of attributes in the VnfInstance that have corresponding attributes \n in the VNFD shall be kept in sync with the values in the VNFD.\nNOTE 2:\tETSI GS NFV-SOL 001 [14] specifies the structure and format of the VNFD based on TOSCA specifications. NOTE 3:\tVNF configurable properties are sometimes also referred to as configuration parameters applicable \n to a VNF. Some of these are set prior to instantiation and cannot be modified if the VNF is instantiated, \n some are set prior to instantiation (are part of initial configuration) and can be modified later, \n and others can be set only after instantiation. The applicability of certain configuration may \n depend on the VNF and the required operation of the VNF at a certain point in time.\nNOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes \n of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared in the VNFD with a defined \n initial value. The defined initial values can be declared in the VNFD, and/or, in case of \"metadata\", \n obtained from the \"CreateVnfRequest\" structure. Child attributes of \"vnfConfigurableProperties\", \n \"metadata\" and \"extensions\" that have no defined initial value shall not be created, in order to be \n consistent with the semantics of the JSON Merge Patch method (see IETF RFC 7396) that interprets null \n values as deletion request.\nNOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a \n multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same \n VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed \n multi-site VL instance (refer to clause 5.5.3.3).\nNOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity, they shall \n not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\nNOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing \n the trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\nNOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the \n VNF LCM operation explicitly indicates the scale level for the aspect.\nNOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n","type":"object","required":["id","vnfdId","vnfProvider","vnfProductName","vnfSoftwareVersion","vnfdVersion","instantiationState","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceName":{"description":"Name of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfInstanceDescription":{"description":"Human-readable description of the VNF instance. This attribute can be modified with the PATCH method.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"Provider of the VNF and the VNFD. The value is copied from the VNFD.\n","type":"string"},"vnfProductName":{"description":"Name to identify the VNF Product. The value is copied from the VNFD.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vimConnectionInfo":{"description":"Information about VIM or CISM connections to be used for managing the resources for the VNF instance. The keys of the map, each of which identifies information about a particular VIM connection, are managed by the NFVO and referenced from other data structures via the \"vimConnectionId\" attribute. This attribute shall only be supported and present if - the resources of at least of the VNFCs are managed by a VIM and VNF-related resource management in direct mode is applicable. - the resources of at least of the VNFCs are managed by a CISM. This attribute can be modified with the PATCH method. If VIM connection information is provisioned to the VNFM by means outside the scope of the present document, the information in the \"vimConnectionInfo\" attribute provides necessary information for binding the VnfInstance representing the \"Individual VNF instance\" to the applicable VIM connection information used to perform resource management for the VNF instance. See also the definition of the \"VimConnectionInfo\" in clause 4.4.1.6.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"cirConnectionInfo":{"description":"Information about the CIR connection for managing OS container images for the VNF instance. Shall be present when all or part of the VNF is realized by a set of OS containers and shall be absent otherwise.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mciopRepositoryInfo":{"description":"Information about the MCIOP repository for the VNF instance. Shall be present when all or part of the VNF is realized by a set of OS containers and shall be absent otherwise. See note 1.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"certificateInfo":{"description":"This type provides input information related to certificate and certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateConfigurationInfo":{"description":"This type provides input information related to certificate management.\n","type":"object","required":["securityPolicy"],"properties":{"certificateBaseProfile":{"description":"Information for certificate profile.","type":"array","items":{"description":"NOTE: At least one overriding attributes shall be present, otherwise shall be absent.\nThis type provides input information to override certificate base profile for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"issuer":{"description":"Issuer of certificates. See note.","type":"string"},"issuerUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subject":{"description":"This type provides input information related to the subject of the certificate.\nNOTE: At least one overriding attributes shall be present, otherwise shall be absent.\n","type":"object","properties":{"commonName":{"description":"Information of the certification target subject FQDN. Can be set empty when this certificate is used for encrypted communication using IP address. See note.\n","type":"string"},"organization":{"description":"Information of the certification target subject Organization. See note.","type":"string"},"country":{"description":"Information of the certification target subject Country. See note.","type":"string"},"state":{"description":"Information of the certification target subject State. See note.","type":"string"},"locality":{"description":"Information of the certification target subject Locality. See note.","type":"string"},"emailAddress":{"description":"Information of the certification contact email address. See note.","type":"string"}}},"subjectUniqueIdentifier":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"basicConstraints":{"description":"Basic constraints of certificates. See note.","type":"string"},"issuerAltName":{"description":"Alternative name of issuer of certificates in this NS. See note.","type":"array","items":{"type":"string"}},"subjectAltName":{"description":"Alternative name of subject of certificates. Shall be present when this certificate is used for encrypted communication using IP address and subjectAltName attribute of CertificateBaseProfile in CertificateDesc of VNFD is empty (see ETSI GS NFV-IFA 011 [14], clause 7.1.19.4). See note.\n","type":"array","items":{"type":"string"}},"nameConstraints":{"description":"Name constraints of certificates. See note.","type":"array","items":{"type":"string"}}}}},"securityPolicy":{"description":"Information for security policy to be satisfied for certificate.","type":"array","items":{"description":"This type provides input information related to security policy for certificate management.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"maxValidityPeriod":{"description":"Allowed max validity period for certificates.","type":"number"},"allowedAlgorithm":{"description":"Allowed signature algorithm.","type":"string"},"minimumKeyLength":{"description":"Minimum key length for certificates.","type":"number"}}}},"delegationSupportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"cmfInfo":{"description":"This type provides input information related to CMF for certificate management.\n","type":"object","required":["id","endPoint","supportedProtocol"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"endPoint":{"description":"End point of CMF instance.","type":"object","properties":{"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"},"link":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"supportedProtocol":{"description":"Supported protocols by CMF instance.","type":"array","items":{"description":"Supported protocol by CMF instance.","type":"string","enum":["CMP","CMPv2","EST","SCEP"]}},"certificateChain":{"description":"Certificate chain that this CMF provides.","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"certificateContents":{"description":"Information for contents of issued certificates. The information contained in this attribute may be updated over time during the VNF LCM, e.g., certificate(s) renewal.\n","type":"array","items":{"description":"This type provides input information related to certificate content.\nNOTE: The CertificateDesc data type is defined in clause 7.1.19.2 of ETSI GS NFV IFA 011 [10].\n","type":"object","required":["id","certificateDescId","certificateType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"certificateType":{"description":"Type of this certificate.","type":"string","enum":["VNFCI_CERT","VNFOAM_CERT"]},"supportedCertificateManagements":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"version":{"description":"A version.\n","type":"string"},"serialNumber":{"description":"Serial number of this certificate.","type":"integer"},"signatureAlgorithm":{"description":"Algorithm of this certificate's signature.","type":"string"},"issuer":{"description":"Issuer of this certificate.","type":"string"},"notBefore":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"notAfter":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"subject":{"description":"Subject of this certificate.","type":"string"},"publicKeyAlgorithm":{"description":"Algorithm of this certificate's public key.","type":"string"},"publicKey":{"description":"Public key of this certificate.","type":"string"},"certificateExtensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"instantiationState":{"description":"The instantiation state of the VNF. Permitted values: - NOT_INSTANTIATED: The VNF instance is terminated or not instantiated. - INSTANTIATED: The VNF instance is instantiated.\n","type":"string","enum":["NOT_INSTANTIATED","INSTANTIATED"]},"instantiatedVnfInfo":{"description":"Information specific to an instantiated VNF instance. This attribute shall be present if the instantiateState attribute value is INSTANTIATED.\n","type":"object","required":["flavourId","vnfState"],"properties":{"flavourId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfState":{"description":"STARTED: The VNF instance is up and running. STOPPED: The VNF instance has been shut down.\n","type":"string","enum":["STARTED","STOPPED"]},"vnfPowerState":{"description":"This type represents information about the power state of a VNF instance.\n","type":"object","required":["powerProfileId","name"],"properties":{"powerProfileId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"Name of the power profile as provided in the VNFD.\n","type":"string"},"powerConsumptionInfo":{"description":"This type represents information about estimated power consumption of the resources associated with the power profile, as provided in the VNFD.\n","type":"object","required":["minPowerConsumption","maxPowerConsumption","averagePowerConsumption"],"properties":{"minPowerConsumption":{"description":"Minimum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"maxPowerConsumption":{"description":"Maximum power consumption of this power profile. Unit is KW/h.\n","type":"integer"},"averagePowerConsumption":{"description":"Average power consumption of this power profile. Unit is KW/h.\n","type":"integer"}}}}},"scaleStatus":{"description":"Scale status of the VNF, one entry per aspect. Represents for every scaling aspect how \"big\" the VNF has been scaled w.r.t. that aspect.\nThis attribute shall be present if the VNF supports scaling. See clause B.2 for an explanation of VNF scaling.\nFor an aspect that has not been deployed because the related deployableModule has not been selected, it indicates the scale level that has been requested in the instantiation or in a scaling operation, or, if none has been requested in any of them, the scale level applicable to the aspect based on the default instantiation level. See note 8.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"maxScaleLevels":{"description":"Maximum allowed scale levels of the VNF, one entry per aspect. This attribute shall be present if the VNF supports scaling.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"selectedDeployableModule":{"description":"References a currently selected deployable module, as defined in the VNFD, that has already completed the instantiation of its VNFCs.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceCapacityDefinition":{"description":"Shows current values of VDU attributes related to resource capacity, if different to the default values from the VNFD, as indicated in the (one or more) request(s) of all completed VNF LCM operation(s) that contain this attribute. If an attribute value has been modified multiple times, only the last value is shown. The values indicated in this attribute are applicable to all VNFC instances based on the VDU to which the resourceCapacityDefinition is related.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes.\nThe tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request.\nAt most one tag can be included when the data type is used in a VNF LCM operation request.\nWhen the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.\n","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced.\n","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute 'type' indicates OSCONTAINER and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource. See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resource property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for this virtual compute descriptor. The value is a numberthat indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) that indicates the valid vaues for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"extCpInfo":{"description":"Information about the external CPs exposed by the VNF instance. When trunking is enabled, the list of entries includes both, external CPs corresponding to parent ports of a trunk, and external CPs associated to sub-ports of a trunk.See note 7.\n","type":"array","items":{"description":"This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n","type":"object","required":["id","cpdId","cpConfigId","cpProtocolInfo"],"oneOf":[{"required":["associatedVnfcCpId"]},{"required":["associatedVipCpId"]},{"required":["associatedVnfVirtualLinkId"]}],"properties":{"id":{"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"},"cpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extLinkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"associatedVnfcCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVipCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVirtualCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"associatedVnfVirtualLinkId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 3 and 4.\nIt shall be present if the external CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNF CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpSecurityGroupInfo":{"description":"This type provides the list of active security group rules applied to an external CP instance. The type identifies which \"SecurityGroupRule\" specified in the VNFD are activated and the values of its attributes.\n","type":"object","required":["securityGroupRuleId","etherType","protocol","portRangeMin","portRangeMax"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"description":{"description":"Human readable description of the security group rule.\n","type":"string"},"etherType":{"description":"Indicates the protocol carried over the Ethernet layer. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"protocol":{"description":"Indicates the protocol carried over the IP layer. Permitted values: any protocol defined in the IANA protocol registry (refer to clause 9.10.1.2 ofd ETSI GS NFV-SOL 001 for further information).\n","type":"string"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule.\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule.\n","type":"integer"}}}}}},"vipCpInfo":{"description":"VIP CPs that are part of the VNF instance. Shall be present when that particular VIP CP of the VNFC instance is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","minItems":1,"items":{"description":"This type provides information related to virtual IP (VIP) CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["cpInstanceId","cpdId"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for layer 3. There may be one cpProtocolInfo for layer 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"associatedVnfcCpIds":{"description":"Identifiers of the VnfcCps that share the virtual IP address allocated to the VIP CP instance. See note.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualCpInfo":{"description":"Virtual CPs that are part of the VNF instance. Shall be present when a particular Virtual CP is associated to an external CP of the VNF instance. May be present otherwise.\n","type":"array","items":{"description":"This type provides information related to a virtual CP instance of a VNF.\nNOTE 1: A consumer of the VNF LCM interface can learn the actual VNFC instances implementing the service accessible via the virtual CP instance by querying the \"vnfcResourceInfo\" from the \"InstantiatedVnfInfo\" \n and filtering by corresponding \"vduIds\" values.\nNOTE 2: The information can be omitted because it is already available as part of the external CP information in the VnfExtCpInfo structure.\n","type":"object","required":["cpInstanceId","cpdId","resourceHandle","vduIds"],"properties":{"cpInstanceId":{"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"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Protocol information for this CP. There shall be one cpProtocolInfo for each layer protocol supported. This attribute may be omitted if the virtual CP is exposed as an external CP. See note 2.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vduIds":{"description":"Reference to the VDU(s) which implement the service accessible via the virtual CP instance. See note 1.\n","type":"array","minItems":1,"items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"additionalServiceInfo":{"description":"Additional service identification information of the virtual CP instance.\n","type":"array","items":{"description":"This type provides additional service information of the virtual CP instance used to expose properties of the virtual CP to NFV-MANO.\nNOTE: This attribute shall only be present if additional information is needed to identify the service termination within the VNF, such as for example a URL path information in an HTTP request required \n to allow a single virtual CP IP address to be used for several HTTP based services that use the \n same port number.\n","type":"object","required":["portInfo"],"properties":{"portInfo":{"description":"Service port numbers exposed by the virtual CP instance.\n","minItems":1,"type":"array","items":{"description":"This type describes the service identifying port properties exposed by the virtual CP instance.\n","type":"object","required":["name","port","portConfigurable"],"properties":{"name":{"description":"The name of the port exposed by the virtual CP instance.\n","type":"string"},"protocol":{"description":"The L4 protocol for this port exposed by the virtual CP instance.\nPermitted values: - TCP - UDP - SCTP\n","type":"string","enum":["TCP","UDP","SCTP"]},"port":{"description":"The L4 port number exposed by the virtual CP instance.\n","type":"integer"},"portConfigurable":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"}}}},"serviceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"extVirtualLinkInfo":{"description":"Information about the external VLs the VNF instance is connected to.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"extManagedVirtualLinkInfo":{"description":"Information about the externally-managed internal VLs of the VNF instance. See notes 5 and 6.\n","type":"array","items":{"description":"This type provides information about an externally-managed virtual link. Note: Both \"vnfLinkPort\" and \"vnfNetAttDefResource\" attributes can be present in an \"ExtManagedVirtualLinkInfo\" to indicate that a single internal virtual link is providing connectivity for both VM-based and container-based \n VNFCs.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPorts":{"description":"Link ports of this VL. See note.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"vnfNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL. See note.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"extManagedMultisiteVirtualLinkId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"routingResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"monitoringParameters":{"description":"Active monitoring parameters.\n","type":"array","items":{"description":"This type represents a monitoring parameter that is tracked by the VNFM,\n","type":"object","required":["id","performanceMetric"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"Human readable name of the monitoring parameter, as defined in the VNFD.\n","type":"string"},"performanceMetric":{"description":"Performance metric that is monitored. This attribute shall contain the related \"Measurement Name\" value as defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"}}}},"localizationLanguage":{"description":"Information about localization language of the VNF (includes e.g. strings in the VNFD). The localization languages supported by a VNF can be declared in the VNFD, and localization language selection can take place at instantiation time. The value shall comply with the format defined in IETF RFC 5646.\n","type":"string"},"vnfcResourceInfo":{"description":"Information about the virtualised compute and storage resources used by the VNFCs of the VNF instance.\n","type":"array","items":{"description":"This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure of\n information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n a) For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n b) For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\nNOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on \n TOSCA specifications.\nNOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an \n internal VL that exposes an external CP. A VNFC CP is \"exposed as\" an external \n CP if it is connected directly to an external VL.\nNOTE 3:\tThe information can be omitted because it is already available as part of the \n external CP information.\nNOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\"\n structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVnfc\" structure in the VNF LCM operation occurrence notifications\n or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\nNOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment\n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. \nNOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n","type":"object","required":["id","vduId","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResourceIds":{"description":"References to the VirtualStorage resources or references to Storage MCIOs. The value refers to a VirtualStorageResourceInfo item in the VnfInstance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcCpInfo":{"description":"CPs of the VNFC instance. Shall be present when that particular CP of the VNFC instance is exposed as an external CP of the VNF instance or is connected to an external CP of the VNF instance. See note 2. May be present otherwise. See note 7.\n","type":"array","items":{"type":"object","required":["id","cpdId"],"properties":{"id":{"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"},"vnfExtCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpProtocolInfo":{"description":"Network protocol information for this CP. May be omitted if the VNFC CP is exposed as an external CP. See note 3.\n","type":"array","items":{"description":"This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"The identifier of layer(s) and protocol(s) associated to the network address information.\nPermitted values: - IP_OVER_ETHERNET\n - IP_FOR_VIRTUAL_CP\nSee note.\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationId":{"description":"Identification of the network segment to which the Cp instance connects to. See notes 3 and 4.\n","type":"string"},"ipAddresses":{"description":"Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["addresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"addresses":{"description":"Fixed addresses assigned (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"isDynamic":{"description":"Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if \"addresses\" is present and shall be absent otherwise.\n","type":"boolean"},"addressRange":{"description":"An IP address range used, e.g. in case of egress connections. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents information about a network address that has been assigned to a virtual CP.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: - IPV4 - IPV6\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which an IP address is assigned to the virtual CP.\n","type":"string"}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"vnfLinkPortId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"parentCpId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceInfo” structure that provides the specification of the interface to attach the connection point to a secondary container cluster network. See notes 5 and 6. It shall be present if the internal CP is associated to a VNFC realized by one or a set of OS containers and is connected to a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC CP instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this VNFC instance uses. Shall be present when using in delegation-mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfVirtualLinkResourceInfo":{"description":"Information about the virtualised network resources used by the VLs of the VNF instance. See note 6.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by an internal VL instance in a VNF instance.\nNote: If only the value or the presence of this attribute is changed in the \"VnfVirtualLinkResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including\n a related \"AffectedVirtualLink\" structure in the VNF LCM operation occurrence notifications or the\n \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","vnfVirtualLinkDescId","networkResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLinkPorts":{"description":"Links ports of this VL. Shall be present when the linkPort is used for external connectivity by the VNF (refer to VnfLinkPortInfo). May be present otherwise.\n","type":"array","items":{"description":"This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"cpInstanceType":{"description":"Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n","type":"string","enum":["VNFC_CP","EXT_CP"]},"vipCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"virtualStorageResourceInfo":{"description":"Information on the virtualised storage resource(s) used as storage for the VNF instance.\n","type":"array","items":{"description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance.\nNote: If only the value or the presence of this attribute is changed in the \"VirtualStorageResourceInfo\" structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVirtualStorage\" structure in the VNF LCM operation occurrence\n notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n","type":"object","required":["id","virtualStorageDescId","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"reservationId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mcioInfo":{"description":"Information on the MCIO(s) representing VNFC instance(s) realized by one or a set of OS containers and created from the same VDU for the VNF instance.\n","type":"array","items":{"description":"This type provides information about an MCIO representing the set of VNFC instances realized by one or a set of OS containers which have been created based on the same VDU. Within the CISM, an MCIO controller monitors the actual state of an MCIO representing the set of VNFC instances realized by one or a set of OS containers and compare it to the desired state For an MCIO related to a VDU that has the attribute isNumOfInstancesClusterBased set to FALSE the desired state is specified in the respective declarative descriptor. For an MCIO related to a VDU that has the attribute isNumOfInstancesClusterBased set to TRUE, the desired state is determined by the number of CIS-nodes in the cluster that fulfil the VDU requirements.as specified in the respective declarative descriptor. It triggers actions toward the CIS to align the actual to the desired state. Monitoring the actual state includes monitoring the number of MCIO instances available at any specific point in time. In addition, an MCIO controller maintains properties and runtime information on the MCIO instances which have been created based on the same VDU. The McioInfo data structure provides the runtime information on the MCIOs obtained from the MCIO controller.\nNOTE: There are different types of MCIOs. The set of VNFC instances based on the same VDU is represented by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type \n of MCIO, e.g. a POD.\n\nRuntime information of the set of OS containers realizing an individual VNFC instance is not part of the McioInfo data structure; such runtime information is provided in the ResourceHandle data structure referenced from the VnfcResourceInfo. The McioInfo does not provide runtime information of a constituent VNFC instance created based on a specific VDU.\nNOTE 1: The type of MCIO as specified in the declarative descriptor of the MCIO, and that can be read from the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the \n “kind” property of the declarative descriptor.\nNOTE 2: If the attribute additionalInfo is present, it may contain runtime information on the actual and desired state of the MCIO(s). \nNOTE 3: When the container infrastructure service is a Kubernetes® instance, the mcioId is the combined values from the kind and name fields of the Kubernetes resource object, separated by a slash. \n Example: \"Deployment/abcd\". \nNOTE 4: When the container infrastructure service is a Kubernetes® instance, the mcioName is the name field of the resource object.\n","type":"object","required":["mcioId","mcioName","mcioNamespace","vduId","cismId","mcioType","desiredInstances","availableInstances"],"properties":{"mcioId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioName":{"description":"Human readable name of this MCIO. See note 4.\n","type":"string"},"mcioNamespace":{"description":"Namespace of this MCIO.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cismId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"mcioType":{"description":"The type of MCIO. Specific values, their semantics and associated MCIO types are defined in clause 5.5.4.9. Additional values are also permitted. See note 1.\n","type":"string","enum":["Deployment","Statefulset","DaemonSet"]},"desiredInstances":{"description":"Number of desired MCIO instances.\n","type":"integer"},"availableInstances":{"description":"Number of available MCIO instances.\n","type":"integer"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"certificateContentId":{"description":"Identifier(s) of the \"CertificateContent\" structure that provides the information of the certificate(s) that this MCIO instance uses. Shall be present when using in delegation mode. Otherwise shall not be present. This attribute shall be supported when delegation mode in certificate management is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfPaasServiceInfo":{"description":"Information on the PaaS Services assigned and used by the VNF instance.\n","type":"array","items":{"description":"This type provides input information about a PaaS Service that is used by a VNF instance. The PaasServiceInfo is comprised of various sets of information. Some information comes from the VNFD, other information comes from the PaaS Service assets provided by the NFVO to the VNFM, and other information is provided at runtime information about the usage of the PaaS Service.\n","type":"object","required":["id","paasServiceId","paasServiceType","paasServiceRequestId","paasServiceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceType":{"description":"The type of PaaS Service. The value of this attribute is expected to be matched against values of the registered PaaS Services in the PSR.","type":"string"},"paasServiceVersion":{"description":"A version.\n","type":"string"},"paasServiceRequestId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"paasServiceHandle":{"description":"This type provides information enabling the access and use of the PaaS Service by the VNF instance. The type and format of the handle depends on the form that the PaaS Service is formed.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"indicators":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"instantiate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"terminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"scaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"heal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"operate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"createSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"revertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"changeCurrentVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}},"recentVnfLcmOperationLinks":{"description":"Links to the most recent LCM operation occurrences related to this resource. See note 9.\n","type":"object","properties":{"recentVnfLcmOperation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmInstantiation":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScale":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmScaleToLevel":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeFlavour":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmTerminate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmHeal":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmOperate":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeExtConn":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmModifyInfo":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmCreateSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmRevertToSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmChangeVnfPkg":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"recentVnfLcmSelectDplMods":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}},"vnfcSnapshots":{"description":"Information about VNFC snapshots constituting this VNF snapshot.\n","type":"array","items":{"description":"This type represents a VNFC snapshot.\nNOTE 1:\tThe identifier of the compute snapshot resource is assigned during creation of a VNFC snapshot \n being returned from the VIM as output data in the response message of the individual resource \n operations. This attribute shall only be present for a VNFC snapshot that has been newly created \n by the VNFM as a result of the \"Create VNF snapshot task\".\nNOTE 2:\tThe identifier of the storage snapshot resource is assigned during creation of a VNFC snapshot being \n returned from the VIM as output data in the response message of the individual resource operations. \n This attribute shall only be present for a VNFC snapshot with an associated storage resource and that \n has been newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n","type":"object","required":["id","vnfcInstanceId","triggeredAt","vnfcResourceId"],"properties":{"id":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"vnfcInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"creationStartedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"creationFinishedAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfcResourceInfoId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"computeSnapshotResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"storageSnapshotResources":{"description":"Mapping of the storage resources associated to the VNFC with the storage snapshot resources.\n","type":"array","items":{"type":"object","required":["storageResourceId"],"properties":{"storageResourceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"storageSnapshotResource":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"vnfStateSnapshotInfo":{"description":"This type represents information about VNF-specific state snapshot data.\n","type":"object","required":["checksum","isEncrypted"],"properties":{"checksum":{"description":"Cheksum description\n","type":"string"},"isEncrypted":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfStateSnapshot":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}}},"IndividualVnfSnapshot.Patch.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the \"Individual VNF\nsnapshot\" resource.\nTypically, this is due to the fact another\nmodification is ongoing or that the \"Individual VNF\nsnapshot\" resource information is not empty due to\na previously successful modification or currently\nbeing modified due to an underlying VNF snapshot\noperation.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute should\nconvey more information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualVnfSnapshot.Patch.412":{"description":"412 Precondition Failed\n\nShall be returned upon the following error: A precondition given in an HTTP request header is\nnot fulfilled.\nTypically, this is due to an ETag mismatch, indicating that the resource was modified by\nanother entity.\nThe response body should contain a ProblemDetails structure, in which the \"detail\"\nattribute should convey more information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualVnfSnapshot.Delete.204":{"description":"204 NO CONTENT\n\nShall be returned when the VNF snapshot resource and the associated VNF snapshot were\ndeleted successfully.\nThe response body shall be empty.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualVnfSnapshot.Delete.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the VNF snapshot\nis in use by some operation such as reverting a VNF\ninstance to a VNF snapshot or creating a VNF\nsnapshot package.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualVnfSnapshotState.Get.200":{"description":"200 OK\n\nShall be returned when the whole content of the VNF state snapshot file has been read successfully.\n\nThe message content shall contain a copy of the VNF state snapshot file and the \"Content-Type\" HTTP\nheader shall be set according to the content type of the VNF state snapshot file. If the VNF state\nsnapshot content is encrypted, the header shall be set to the value \"application/cms\" (IETF RFC 7193).\n\nIf the content type cannot be determined, the header shall be set to the value \"application/octet-stream\".\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/*":{"schema":{"type":"string","format":"binary"}}}},"IndividualVnfSnapshotState.Get.206":{"description":"206 PARTIAL CONTENT\n\nIf the VNFM supports range requests, this response shall be returned when a single consecutive byte\nrange from the content of the VNF state snapshot file has been read successfully according to the request.\n\nThe response body shall contain the requested part of the VNF state snapshot file. The \"Content-Type\" HTTP\nheader shall be set according to the content type of the VNF state snapshot file. If the content type cannot\nbe determined, the header shall be set to the value \"application/octet-stream\".\n\nThe \"Content-Range\" HTTP header shall be provided according to IETF RFC 7233.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Range":{"required":true,"style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/*":{"schema":{"type":"string","format":"binary"}}}},"IndividualVnfSnapshotState.Get.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that the VNF\nsnapshot creation process is not completed.\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualVnfSnapshotState.Get.416":{"description":"416 RANGE NOT SATISFIABLE\n\nShall be returned upon the following error: The byte\nrange passed in the \"Range\" header did not match\nany available byte range in the VNF state snapshot\nfile (e.g. \"access after end of file\").\nThe response body may contain a ProblemDetails\nstructure\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}}}}}} diff --git a/v5.3.1/SOL003-VNFLifecycleManagement-API.yaml b/v5.3.1/SOL003-VNFLifecycleManagement-API.yaml new file mode 100644 index 00000000..381fae02 --- /dev/null +++ b/v5.3.1/SOL003-VNFLifecycleManagement-API.yaml @@ -0,0 +1,103790 @@ +openapi: 3.0.2 +info: + title: SOL003 - VNF Lifecycle Management interface + description: | + SOL003 - VNF Lifecycle Management interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '2.16.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 003 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf +servers: + - url: 'http://127.0.0.1/vnflcm/v2' + - url: 'https://127.0.0.1/vnflcm/v2' +paths: + /api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /vnf_instances: + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + post: + description: > + The POST method creates a new VNF instance resource based on a VNF + package that is onboarded + + and in "ENABLED" state. See clause 5.4.2.3.1. + requestBody: + $ref: '#/components/requestBodies/CreateVnfRequest' + responses: + '201': + $ref: '#/components/responses/VNFInstances.Post.201' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/VNFInstances.Post.422' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + get: + description: > + The GET method queries information about multiple VNF instances. See + clause 5.4.2.3.2. + parameters: + - $ref: '#/components/parameters/filter_vnf_instances' + - name: all_fields + description: > + Include all complex attributes in the response. See clause 5.3 of + ETSI GS NFV-SOL 013 [8] for details. The VNFM shall support this + parameter. + in: query + required: false + schema: + type: string + - name: fields + description: > + Complex attributes to be included into the response. See clause 5.3 + of ETSI GS NFV-SOL 013 [8] for details. The VNFM should support this + parameter. + in: query + required: false + schema: + type: string + - name: exclude_fields + description: > + Complex attributes to be excluded from the response. See clause 5.3 + of ETSI GS NFV-SOL 013 [8] for details. The VNFM should support this + parameter. + in: query + required: false + schema: + type: string + - $ref: '#/components/parameters/exclude_default_vnf_instances' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this + resource. + in: query + required: false + schema: + type: string + responses: + '200': + $ref: '#/components/responses/VNFInstances.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + get: + description: > + The GET method retrieves information about a VNF instance by reading an + "Individual VNF instance" resource. + + See clause 5.4.3.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualVnfInstance.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method modifies an "Individual VNF instance" resource. See clause + 5.4.3.3.4. + parameters: + - name: If-Unmodified-Since + description: > + Used to make the request method conditional on the selected + resource representation's last modification date being earlier than + or equal to the date provided in the field-value. If the condition + is not met, the request fails with a "412 Precondition Failed" + response. + required: false + in: header + schema: + type: string + format: date-time + - name: If-Match + description: > + Used to make the request method conditional on the recipient origin + server either having at least one current representation of the + target resource, when the field-value is "*", or having a current + representation of the target resource that has an entity-tag + matching a member of the list of entity-tags provided in the + field-value. If the condition is not met, the request fails with a + "412 Precondition Failed" response. + required: false + in: header + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/VnfInfoModificationRequest' + responses: + '202': + $ref: '#/components/responses/IndividualVnfInstance.Patch.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/IndividualVnfInstance.Patch.409' + '412': + $ref: '#/components/responses/IndividualVnfInstance.Patch.412' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method deletes an "Individual VNF instance" resource. See clause + 5.4.3.3.5. + responses: + '204': + $ref: '#/components/responses/IndividualVnfInstance.Delete.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/IndividualVnfInstance.Delete.409' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/instantiate': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + post: + description: | + The POST method instantiates a VNF instance. See clause 5.4.4.3.1. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/InstantiateVnfRequest' + responses: + '202': + $ref: '#/components/responses/InstantiateVnfInstance.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/InstantiateVnfInstance.Post.409' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/scale': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + post: + description: > + The POST method requests to scale a VNF instance resource incrementally. + See clause 5.4.5.3.1. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/ScaleVnfRequest' + responses: + '202': + $ref: '#/components/responses/ScaleVnfInstance.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/ScaleVnfInstance.Post.404' + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/ScaleVnfInstance.Post.409' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/scale_to_level': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + post: + description: > + The POST method requests to scale a VNF instance resource to a target + level. See clause 5.4.6.3.1. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/ScaleVnfToLevelRequest' + responses: + '202': + $ref: '#/components/responses/ScaleToLevelVnfInstance.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/ScaleToLevelVnfInstance.Post.404' + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/ScaleToLevelVnfInstance.Post.409' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/change_flavour': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + post: + description: > + The POST method changes the deployment flavour of a VNF instance. See + clause 5.4.7.3.1. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/ChangeVnfFlavourRequest' + responses: + '202': + $ref: '#/components/responses/ChangeFlavourVnfInstance.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/ChangeFlavourVnfInstance.Post.404' + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/ChangeFlavourVnfInstance.Post.409' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/terminate': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + post: + description: > + The POST method triggers the VNFM to terminate a VNF instance and to + request to the VIM the + + release of its used virtualised resources. See clause 5.4.8.3.1. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/TerminateVnfRequest' + responses: + '202': + $ref: '#/components/responses/TerminateVnfInstance.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/TerminateVnfInstance.Post.409' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/heal': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + post: + description: | + The POST method requests to heal a VNF instance. See clause 5.4.9.3.1. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/HealVnfRequest' + responses: + '202': + $ref: '#/components/responses/HealVnfInstance.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/HealVnfInstance.Post.404' + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/HealVnfInstance.Post.409' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/operate': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + post: + description: > + The POST method changes the operational state of a VNF instance. See + clause 5.4.10.3.1. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/OperateVnfRequest' + responses: + '202': + $ref: '#/components/responses/OperateVnfInstance.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/OperateVnfInstance.Post.404' + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/OperateVnfInstance.Post.409' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/change_ext_conn': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + post: + description: > + The POST method changes the external connectivity of a VNF instance. See + clause 5.4.11.3.1. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/ChangeExtVnfConnectivityRequest' + responses: + '202': + $ref: '#/components/responses/ChangeExtConnVnfInstance.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/ChangeExtConnVnfInstance.Post.409' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/change_vnfpkg': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + post: + description: > + The POST method changes the current VNF package on which the VNF + instance is based. See clause 5.4.11a.3.1. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/ChangeCurrentVnfPkgRequest' + responses: + '202': + $ref: '#/components/responses/ChangeVnfpkgVnfInstance.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/ChangeVnfpkgVnfInstance.Post.409' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /vnf_lcm_op_occs: + get: + description: > + The API consumer can use this method to query status information about + multiple VNF lifecycle management + + operation occurrences. See clause 5.4.12.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - $ref: '#/components/parameters/filter_vnf_lcm_op_occs' + - name: all_fields + description: > + Include all complex attributes in the response. See clause 5.3 of + ETSI GS NFV-SOL 013 [8] for details. The VNFM shall support this + parameter. + in: query + required: false + schema: + type: string + - name: fields + description: > + Complex attributes to be included into the response. See clause 5.3 + of ETSI GS NFV-SOL 013 [8] for details. The VNFM should support this + parameter. + in: query + required: false + schema: + type: string + - name: exclude_fields + description: > + Complex attributes to be excluded from the response. See clause 5.3 + of ETSI GS NFV-SOL 013 [8] for details. The VNFM should support this + parameter. + in: query + required: false + schema: + type: string + - $ref: '#/components/parameters/exclude_default_vnf_lcm_op_occs' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this + resource. + in: query + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/VnfLcmOpOccs.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_lcm_op_occs/{vnfLcmOpOccId}': + parameters: + - $ref: '#/components/parameters/VnfLcmOpOccId' + get: + description: > + The API consumer can use this method to retrieve status information + about a VNF lifecycle management operation + + occurrence by reading an "Individual VNF LCM operation occurrence" + resource. See clause 5.4.13.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualVnfLcmOpOcc.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_lcm_op_occs/{vnfLcmOpOccId}/retry': + parameters: + - $ref: '#/components/parameters/VnfLcmOpOccId' + post: + description: > + The POST method initiates retrying a VNF lifecycle operation if that + operation has experienced a temporary + + failure, i.e. the related "Individual VNF LCM operation occurrence" + resource is in "FAILED_TEMP" state. + + See clause 5.4.14.3.1. + parameters: + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + responses: + '202': + $ref: '#/components/responses/RetryVnfLcmOpOcc.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/RetryVnfLcmOpOcc.Post.404' + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/RetryVnfLcmOpOcc.Post.409' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_lcm_op_occs/{vnfLcmOpOccId}/rollback': + parameters: + - $ref: '#/components/parameters/VnfLcmOpOccId' + post: + description: > + The POST method initiates rolling back a VNF lifecycle operation if that + operation has experienced a temporary + + failure, i.e. the related "Individual VNF LCM operation occurrence" + resource is in "FAILED_TEMP" state. + + See clause 5.4.15.3.1. + parameters: + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + responses: + '202': + $ref: '#/components/responses/RollbackVnfLcmOpOcc.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/RollbackVnfLcmOpOcc.Post.404' + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/RollbackVnfLcmOpOcc.Post.409' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_lcm_op_occs/{vnfLcmOpOccId}/fail': + parameters: + - $ref: '#/components/parameters/VnfLcmOpOccId' + post: + description: > + The POST method marks a VNF lifecycle management operation occurrence as + "finally failed" if that operation + + occurrence is in "FAILED_TEMP" state. See clause 5.4.16.3.1. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/FailVnfLcmOpOcc.Post.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/FailVnfLcmOpOcc.Post.404' + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/FailVnfLcmOpOcc.Post.409' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_lcm_op_occs/{vnfLcmOpOccId}/cancel': + parameters: + - $ref: '#/components/parameters/VnfLcmOpOccId' + post: + description: > + The POST method initiates cancelling an ongoing VNF lifecycle operation + while it is being executed or rolled + + back, i.e. the related "Individual VNF LCM operation occurrence" + resource is either in "STARTING" or + + "PROCESSING" or "ROLLING_BACK" state. See clause 5.4.17.3.1. + parameters: + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + responses: + '202': + $ref: '#/components/responses/CancelVnfLcmOpOcc.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/CancelVnfLcmOpOcc.Post.404' + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/CancelVnfLcmOpOcc.Post.409' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /subscriptions: + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + post: + description: | + The POST method creates a new subscription. See clause 5.4.18.3.1. + requestBody: + $ref: '#/components/requestBodies/LccnSubscriptionRequest' + responses: + '201': + $ref: '#/components/responses/Subscriptions.Post.201' + '303': + $ref: '#/components/responses/Subscriptions.Post.303' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/Subscriptions.Post.422' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + get: + description: > + The GET method queries the list of active subscriptions of the + functional block that invokes the method. + + It can be used e.g. for resynchronization after error situations. See + clause 5.4.18.3.2. + parameters: + - $ref: '#/components/parameters/filter_subscriptions' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this + resource. + in: query + required: false + schema: + type: string + responses: + '200': + $ref: '#/components/responses/Subscriptions.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/subscriptions/{subscriptionId}': + parameters: + - $ref: '#/components/parameters/SubscriptionId' + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + get: + description: > + The GET method retrieves information about a subscription by reading an + "Individual subscription" resource. + + See clause 5.4.19.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualSubscription.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + The DELETE method terminates an individual subscription. See clause + 5.4.19.3.5. + responses: + '204': + $ref: '#/components/responses/IndividualSubscription.Delete.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/create_snapshot': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + post: + description: > + The POST method requests taking a snapshot a VNF instance and populating + a previously created VNF snapshot + + resource (refer to clause 5.4.23.3.1) with the snapshot content. See + clause 5.4.21.3.1. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/CreateVnfSnapshotRequest' + responses: + '202': + $ref: '#/components/responses/CreateVnfSnapshotTask.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/CreateVnfSnapshotTask.Post.404' + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/CreateVnfSnapshotTask.Post.409' + '422': + $ref: '#/components/responses/CreateVnfSnapshotTask.Post.422' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/revert_to_snapshot': + parameters: + - $ref: '#/components/parameters/VnfInstanceId' + post: + description: > + The POST method requests reverting a VNF instance to a VNF snapshot. See + clause 5.4.22.3.1. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/RevertToVnfSnapshotRequest' + responses: + '202': + $ref: '#/components/responses/RevertToVnfSnapshotTask.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/RevertToVnfSnapshotTask.Post.404' + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/RevertToVnfSnapshotTask.Post.409' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /vnf_snapshots: + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + post: + description: > + The POST method creates a new "Individual VNF snapshot" resource. See + clause 5.4.23.3.1. + requestBody: + $ref: '#/components/requestBodies/CreateVnfSnapshotInfoRequest' + responses: + '201': + $ref: '#/components/responses/VnfSnapshots.Post.201' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + get: + description: > + The GET method queries information about multiple VNF snapshots. This + method shall follow the provisions specified in the tables 5.4.23.3.2-1 + and 5.4.23.3.2-2 for URI query parameters, request and response data + structures, and response codes. + parameters: + - $ref: '#/components/parameters/filter_vnf_snapshots' + - name: all_fields + description: > + Include all complex attributes in the response. See clause 5.3 of + ETSI GS NFV-SOL 013 [8] for details. The VNFM shall support this + parameter. + in: query + required: false + schema: + type: string + - name: fields + description: > + Complex attributes to be included into the response. See clause 5.3 + of ETSI GS NFV-SOL 013 [8] for details. The VNFM should support this + parameter. + in: query + required: false + schema: + type: string + - name: exclude_fields + description: > + Complex attributes to be excluded from the response. See clause 5.3 + of ETSI GS NFV-SOL 013 [8] for details. The VNFM should support this + parameter. + in: query + required: false + schema: + type: string + - $ref: '#/components/parameters/exclude_default_vnf_snapshots' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this + resource. + in: query + required: false + schema: + type: string + responses: + '200': + $ref: '#/components/responses/VnfSnapshots.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_snapshots/{vnfSnapshotInfoId}': + parameters: + - $ref: '#/components/parameters/VnfSnapshotInfoId' + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + get: + description: > + The GET method retrieves information about a VNF snapshot by reading an + "Individual VNF snapshot" resource. + + See clause 5.4.24.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualVnfSnapshot.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method modifies an "Individual VNF snapshot" resource. See clause + 5.4.24.3.4. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + - name: If-Unmodified-Since + description: > + Used to make the request method conditional on the selected + resource representation's last modification date being earlier than + or equal to the date provided in the field-value. If the condition + is not met, the request fails with a "412 Precondition Failed" + response. + required: false + in: header + schema: + type: string + format: date-time + - name: If-Match + description: > + Used to make the request method conditional on the recipient origin + server either having at least one current representation of the + target resource, when the field-value is "*", or having a current + representation of the target resource that has an entity-tag + matching a member of the list of entity-tags provided in the + field-value. If the condition is not met, the request fails with a + "412 Precondition Failed" response. + required: false + in: header + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/VnfSnapshotInfoModificationRequest' + responses: + '200': + $ref: '#/components/responses/IndividualVnfSnapshot.Patch.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/IndividualVnfSnapshot.Patch.409' + '412': + $ref: '#/components/responses/IndividualVnfSnapshot.Patch.412' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method deletes an "Individual VNF snapshot" resource and the + associated VNF snapshot information + + managed by the VNFM, and any resource associated to the VNF snapshot + managed by the VIM. See clause 5.4.24.3.5. + responses: + '204': + $ref: '#/components/responses/IndividualVnfSnapshot.Delete.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/IndividualVnfSnapshot.Delete.409' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_snapshots/{vnfSnapshotInfoId}/vnf_state_snapshot': + parameters: + - $ref: '#/components/parameters/VnfSnapshotInfoId' + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + get: + description: > + The GET method fetches the content of the VNF state snapshot. + + This method shall follow the provisions specified in the tables + 5.4.25.3.2-1 and 5.4.25.3.2-2 + + for URI query parameters, request and response data structures, and + response codes. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - $ref: '#/components/parameters/Range' + responses: + '200': + $ref: '#/components/responses/IndividualVnfSnapshotState.Get.200' + '206': + $ref: '#/components/responses/IndividualVnfSnapshotState.Get.206' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/IndividualVnfSnapshotState.Get.409' + '416': + $ref: '#/components/responses/IndividualVnfSnapshotState.Get.416' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_instances/{vnfInstanceId}/select_depl_mods': + parameters: + - $ref: '#/components/parameters/VnfInstanceId_1' + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + post: + description: > + The POST method requests to select deployable modules of a VNF instance + and therefore to instantiate or terminate + + VNFC instances according to the selected deployable modules. + requestBody: + $ref: '#/components/requestBodies/SelectVnfDeployableModulesRequest' + responses: + '202': + $ref: '#/components/responses/Selectdeployablemodules.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 409 CONFLICT + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + parameters: + filter_vnf_instances: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part + of the URI query string. The NFVO may supply this parameter. All + attribute names that appear in the VnfInstance and in data types + referenced from it shall be supported by the VNFM in the filter + expression. + in: query + required: false + schema: + type: string + exclude_default_vnf_instances: + name: exclude_default + in: query + description: >- + Indicates to exclude the following complex attributes from the response. + See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM shall + support this parameter. The following attributes shall be excluded from + the VnfInstance structure in the response body if this parameter is + provided, or none of the parameters "all_fields", "fields", + "exclude_fields", "exclude_default" are provided: + - vnfConfigurableProperties + - vimConnectionInfo + - instantiatedVnfInfo + - metadata + - extensions + required: false + schema: + type: string + filter_vnf_lcm_op_occs: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part + of the URI query string. The NFVO may supply this parameter. All + attribute names that appear in the VnfLcmOpOcc and in data types + referenced from it shall be supported by the VNFM in the filter + expression. + in: query + required: false + schema: + type: string + exclude_default_vnf_lcm_op_occs: + name: exclude_default + in: query + description: >- + Indicates to exclude the following complex attributes from the response. + See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM shall + support this parameter. The following attributes shall be excluded from + the VnfLcmOpOcc structure in the response body if this parameter is + provided, or none of the parameters "all_fields," "fields", + "exclude_fields", "exclude_default" are provided: + - operationParams + - error + - resourceChanges + - changedInfo + - changedExtConnectivity + - lcmCoordinations + - modificationsTriggeredByVnfPkgChange + - warnings + required: false + schema: + type: string + filter_subscriptions: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part + of the URI query string. The NFVO may supply this parameter. All + attribute names that appear in the LccnSubscription and in data types + referenced from it shall be supported by the VNFM in the filter + expression. + in: query + required: false + schema: + type: string + filter_vnf_snapshots: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part + of the URI query string. The NFVO may supply this parameter. All + attribute names that appear in the VnfSnapshot and in data types + referenced from it shall be supported by the VNFM in the filter + expression. + in: query + required: false + schema: + type: string + exclude_default_vnf_snapshots: + name: exclude_default + in: query + description: >- + Indicates to exclude the following complex attributes from the response. + See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM shall + support this parameter. The following attributes shall be excluded from + the VnfSnapshot structure in the response body if this parameter is + provided, or none of the parameters "all_fields," "fields", + "exclude_fields", "exclude_default" are provided: + - vnfInstance + - vnfcSnapshots + required: false + schema: + type: string + VnfInstanceId: + name: vnfInstanceId + in: path + description: > + Identifier of the VNF instance for the VNF snapshot to be reverted to. + This identifier can be retrieved from the resource + + referenced by the "Location" HTTP header in the response to a POST + request creating a new "Individual VNF instance" resource. + + It can also be retrieved from the "id" attribute in the message content + of that response. + required: true + style: simple + explode: false + schema: + type: string + VnfLcmOpOccId: + name: vnfLcmOpOccId + in: path + description: > + Identifier of a VNF lifecycle management operation occurrence. This + identifier can be retrieved from the resource + + referenced by the "Location" HTTP header in the response to a PATCH or + POST request triggering a VNF LCM operation. + + It can also be retrieved from the "vnfLcmOpOccId" attribute in the + VnfLcmOperationOccurrenceNotification. + required: true + style: simple + explode: false + schema: + type: string + SubscriptionId: + name: subscriptionId + in: path + description: > + Identifier of this subscription. This identifier can be retrieved from + the resource referenced by the "Location" + + HTTP header in the response to a POST request creating a new + subscription resource. It can also be retrieved from + + the "id" attribute in the message content of that response. + required: true + style: simple + explode: false + schema: + type: string + VnfSnapshotInfoId: + name: vnfSnapshotInfoId + in: path + description: > + Identifier of the "Individual VNF snapshot" resource. This identifier + can be retrieved + + from the resource referenced by the "Location" HTTP header in the + response to a POST request + + creating a new VNF snapshot resource. It can also be retrieved from the + "id" attribute in + + the message content of that response. + required: true + style: simple + explode: false + schema: + type: string + VnfInstanceId_1: + name: vnfInstanceId + in: path + description: > + Identifier of the VNF instance of which the deployable modules are + requested to be selected. See note. + + + NOTE: This identifier can be retrieved from the resource referenced by + the "Location" HTTP header + + in the response to a POST request creating a new "Individual VNF + instance" resource. It can + + also be retrieved from the "id" attribute in the message content of that + response. + required: true + style: simple + explode: false + schema: + type: string + Range: + name: Range + in: header + description: | + The request may contain a "Range" HTTP header to obtain single + range of bytes from a VNF state snapshot file. This can be used to + continue an aborted transmission. + If the "Range" header is present in the request and the VNFM + does not support responding to range requests with a 206 + response, it shall return a 200 OK response instead. + schema: + type: string + requestBodies: + CreateVnfRequest: + description: The VNF creation parameters + content: + application/json: + schema: + description: > + This type represents request parameters for the "Create VNF + identifier" operation. + type: object + required: + - vnfdId + properties: + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfInstanceName: + description: | + Human-readable name of the VNF instance to be created. + type: string + vnfInstanceDescription: + description: | + Human-readable description of the VNF instance to be created. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + certificateConfigurationData: + description: > + This type provides input information related to certificate + management. + + ETSI GS NFV-SOL 009 [i.18] specifies the means to discover the + applicable certificate management mode of VNFM and configure + into the NFVO applicable certificate management mode via the + "NFV-MANO Configuration and Information Management" interface + type: object + properties: + overridingCertificateProfiles: + description: > + Overriding certificate profile. This overrides the + certificateBaseProfile provided in the VNFD, and the CA + and CMF can additionally override aspects of this + certificateBaseProfile at later point in the VNF lifecycle + if necessary to meet operator security policy. + type: array + items: + description: > + NOTE: At least one overriding attributes shall be + present, otherwise shall be absent. + + This type provides input information to override + certificate base profile for certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + issuer: + description: Issuer of certificates. See note. + type: string + issuerUniqueIdentifier: + description: > + An identifier with the intention of being globally + unique. + type: string + subject: + description: > + This type provides input information related to the + subject of the certificate. + + NOTE: At least one overriding attributes shall be + present, otherwise shall be absent. + type: object + properties: + commonName: + description: > + Information of the certification target subject + FQDN. Can be set empty when this certificate is + used for encrypted communication using IP + address. See note. + type: string + organization: + description: >- + Information of the certification target subject + Organization. See note. + type: string + country: + description: >- + Information of the certification target subject + Country. See note. + type: string + state: + description: >- + Information of the certification target subject + State. See note. + type: string + locality: + description: >- + Information of the certification target subject + Locality. See note. + type: string + emailAddress: + description: >- + Information of the certification contact email + address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of being globally + unique. + type: string + basicConstraints: + description: Basic constraints of certificates. See note. + type: string + issuerAltName: + description: >- + Alternative name of issuer of certificates in this + NS. See note. + type: array + items: + type: string + subjectAltName: + description: > + Alternative name of subject of certificates. Shall + be present when this certificate is used for + encrypted communication using IP address and + subjectAltName attribute of CertificateBaseProfile + in CertificateDesc of VNFD is empty (see ETSI GS + NFV-IFA 011 [14], clause 7.1.19.4). See note. + type: array + items: + type: string + nameConstraints: + description: Name constraints of certificates. See note. + type: array + items: + type: string + securityPolicy: + description: | + Security policy to be satisfied for the certificate. + type: array + items: + description: > + This type provides input information related to security + policy for certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + maxValidityPeriod: + description: Allowed max validity period for certificates. + type: number + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: number + cmfData: + description: > + This type provides input information related to CMF for + certificate management. + type: object + required: + - endPoint + - supportedProtocols + properties: + endPoint: + description: End point of CMF instance. + type: object + properties: + 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 + link: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + supportedProtocols: + description: Supported protocols by CMF instance. + type: array + items: + description: Supported protocol by CMF instance. + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + required: true + VnfInfoModificationRequest: + description: | + Parameters for the VNF modification, as defined in clause 5.5.2.12. + content: + application/merge-patch+json: + schema: + description: > + This type represents attribute modifications for an "Individual + VNF instance" resource, i.e. modifications to a resource + representation based on the "VnfInstance" data type. + type: object + properties: + vnfInstanceName: + description: | + A string defined in IETF RFC 8259. + type: string + vnfInstanceDescription: + description: | + A string defined in IETF RFC 8259. + type: string + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + vimConnectionInfo: + description: > + Modifications of the "vimConnectionInfo" attribute. If + present, these modifications shall be applied according to the + rules of JSON Merge Patch (see IETF RFC 7396 [5]). + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines the + structure of the "interfaceInfo" and "accessInfo" + attributes, based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values is + expected to change over time as new types or versions of + VIMs become available. The ETSI NFV registry of + VIM-related information provides access to information + about VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The structure of + the registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + required: true + InstantiateVnfRequest: + description: Parameters for the VNF instantiation. + content: + application/json: + schema: + description: "This type represents request parameters for the \"Instantiate VNF\" operation.\n* NOTE 1:\tThe indication of externally-managed internal VLs is needed in case \n networks have been pre-configured for use with certain VNFs, for instance \n to ensure that these networks have certain properties such as security or \n acceleration features, or to address particular network topologies. \n The present document assumes that externally-managed internal VLs are \n managed by the NFVO and created towards the VIM.\n* NOTE 2:\tIt is possible to have several ExtManagedVirtualLinkData for the same VNF \n internal VL in case of a multi-site VNF spanning several VIMs. The set of \n ExtManagedVirtualLinkData corresponding to the same VNF internal VL shall \n indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed \n multi-site VL instance (refer to clause 4.4.1.12).\n* NOTE 3: The target size for VNF instantiation may be specified in either instantiationLevelId or targetScaleLevelInfo, but\n not both. If none of the two attributes (instantiationLevelId or targetScaleLevelInfo) are present, the default\n instantiation level as declared in the VNFD shall be used.\n* NOTE 4: If targetScaleLevelInfo is specified, information provided in targetScaleLevelInfo shall be used for instantiating\n scalable constituents of the VNF (e.g, VDUs/VLs). For scaling aspects not specified in targetScaleLevelInfo or\n for the VNF constituents (e.g.,VDUs/VLs) that are not scalable, the default instantiation level as declared in the\n VNFD shall be used for instantiation.\n* NOTE 5: If the referenced instantiationLevel or the targetScaleLevelInfo contain information related to VNFCs that are \n not going to be instantiated due to the selection of deployable modules, the information is stored in the VNFM \n for later use and included in the instantiatedVnfInfo. If none of the attributes is present, the information from the \n defaultInstantiationLevel related to those VNFCs is stored and included in the instantiatedVnfInfo. If, during the \n lifecycle of the VNF, as a result of a change of the selected deployable modules any of those VNFCs is going to \n be instantiated, the stored information determines the number of instances, unless the request that triggered \n the change also contains information about the number of instances.\n" + type: object + required: + - flavourId + properties: + flavourId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + instantiationLevelId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + targetScaleLevelInfo: + description: > + This attribute is applicable if VNF supports target scale + level instantiation. For each scaling aspect of the current + deployment flavour, the attribute specifies the scale level of + VNF constituents (e.g., VDU level) to be instantiated. See + notes 3, 4, and 5. + type: array + items: + description: > + This type represents the scale level of a VNF instance + related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being globally + unique. + type: string + extVirtualLinks: + description: > + Information about external VLs to connect the VNF to, + including configuration information for the CPs via which the + VNF instance can attach to this VL. The following applies to + the "ExtVirtualLinkData" information provided in this request, + together with the the related overriding information provided + in the "Grant" structure (see clause 9.5.2.3): Even if the VNF + is not instantiated in fully scaled-out state, the API + consumer shall provide enough CP configuration records to + allow connecting the VNF instance, fully scaled out in all + scaling aspects, to the external VLs. + type: array + items: + description: "This type represents an external VL.\n* NOTE 1:\tA link port is not needed for an external CP instance that exposes a CP in the following cases:\n 1) For a VIP CP directly exposed as an external CP:\n 1.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD.\n 1.2) A dedicated IP address is allocated as VIP address, but the NFVO indicates that no port is needed\n (createExtLinkPort in VnfExtCpConfig set to false).\n 2) For a VIP CP exposed as an external CP via a floating IP address:\n 2.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD, and the VNFC CP\n associated to the VIP CP is also exposed via a floating IP address.\n 3) For a VIRTUAL CP exposed as an external CP.\n 4) For a VNFC CP exposed as an external CP in a secondary container cluster external network or a\n secondary container cluster internal network.\n\n* NOTE 2: An example of the network attachment definition resource when the container infrastructure service\n management is a Kubernetes® instance is a network attachment definition (NAD).\n* NOTE 3: Either \"extCps\" or “extCpsDeletion\" shall be present, but not both.\n" + type: object + required: + - id + - resourceId + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + extCps: + description: > + External CPs of the VNF to be connected to this external + VL. Entries in the list of external CP data that are + unchanged need not be supplied if the ExtVirtualLinkData + structure is part of a request or response that modifies + the external connectivity. See note 3. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. + + The entries shall be applied by the VNFM according + to the rules of JSON Merge Patch (see IETF RFC + 7396). See notes 2, 3, 4, 5, 6. In case of + deleting an external CP, the list of instances to + be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extLinkPorts: + description: > + Externally provided link ports to be used to connect + external connection points to this external VL. If this + attribute is not present, the VNFM shall create the link + ports on the external VL except in the cases defined + below. See note 1. + type: array + items: + description: "This type represents an externally provided link port to be used to connect an external connection point to an external VL. * NOTE:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + extNetAttDefResourceData: + description: > + Externally provided network attachment definition + resource(s) that provide the specification of the + interface to attach external CPs to this external VL. + See note 2. It is only applicable if the external VL is + realized by a secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + This type represents a network attachment definition + resource that provides the specification of the + interface to be used to connect one or multiple + connection points to a secondary container cluster + network realizing a VL. + type: object + required: + - netAttDefResourceId + - resourceHandle + properties: + netAttDefResourceId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + extCpsDeletion: + description: > + External CPs of the VNF to be disconnected from this + external VL and to be deleted. See note 3. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. + + The entries shall be applied by the VNFM according + to the rules of JSON Merge Patch (see IETF RFC + 7396). See notes 2, 3, 4, 5, 6. In case of + deleting an external CP, the list of instances to + be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extManagedVirtualLinks: + description: > + Information about internal VLs that are managed by the NFVO. + See note 1 and note 2. + type: array + items: + description: > + This type represents an externally-managed internal VL. + + * NOTE 1: It is only applicable if the externally-managed VL + is realized by a secondary container cluster network. It + shall + not be present otherwise. + * NOTE 2: A link port is not needed for a VNFC internal + connection point connected to a secondary container cluster + network. + * NOTE 3: An example of the network attachment definition + resource when the container infrastructure service + management is a Kubernetes® instance is a network attachment definition (NAD). + + * NOTE 4: In the case that the cloud native template + included in the MCIOP describes the set of VNFC instances, + an + instance of intCp need not be included for each VNFC instance as all instances would contain the same + information. It is sufficient to include one intCp for the related CPD. The case of using, for a scalable VDU, a + cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present + document version + * NOTE 5: Both "vnfLinkPort" and "netAttDefResource" + attributes can be provided in a "ExtManagedVirtualLinkData" + to indicate + that a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs + type: object + required: + - id + - vnfVirtualLinkDescId + - resourceId + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfVirtualLinkDescId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + netAttDefResourceData: + description: > + Externally provided network attachment definition + resource(s) that provide the specification of the + interface to attach VNFC connection points to this + externallymanaged VL. See notes 1, 3 and 5. + type: array + items: + description: > + This type represents a network attachment definition + resource that provides the specification of the + interface to be used to connect one or multiple + connection points to a secondary container cluster + network realizing a VL. + type: object + required: + - netAttDefResourceId + - resourceHandle + properties: + netAttDefResourceId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + intCp: + description: > + Internal CPs of the VNF to be connected to this + externally-managed VL. See note 1 and 4. + type: array + items: + description: > + This type represents input information related to one + or more VNF internal CP instances created based on the + same CPD. + + NOTE: Cardinality greater than 1 is only applicable + for specific cases where more than one network + attachment + definition resource is needed to fulfil the connectivity requirements of the VNF internal CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall + belong to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + type: object + required: + - cpdId + - netAttDefResourceId + properties: + cpdId: + description: > + An identifier with the intention of being globally + unique. + type: string + netAttDefResourceId: + description: > + Identifiers of the “NetAttDefResourceData” + structure that provides the specification of the + interface to attach the VNF internal CP created + from the CPD identified by cpdId to a secondary + container cluster network. See note. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfLinkPort: + description: > + Externally provided link ports to be used to connect + VNFC connection points to this externally-managed VL on + this network resource. If this attribute is not present, + the VNFM shall create the link ports on the + externally-managed VL. See notes 2 and 5. + type: array + items: + description: > + This type represents an externally provided link port + to be used to connect a VNFC connection point to an + externally managed VL. + type: object + required: + - vnfLinkPortId + - resourceHandle + properties: + vnfLinkPortId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + extManagedMultisiteVirtualLinkId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimConnectionInfo: + description: > + Information about VIM or CISM connections to be used for + managing the resources for the VNF instance, or refer to + external/externally-managed virtual links. This attribute + shall only be supported and may be present if - the resources + for at least one of the VNFCs shall be managed by a VIM and + VNF-related resource management in direct mode is applicable. + - the resources for at least one of the VNFCs shall be managed + by a CISM. The VNFM shall apply the content of this attribute + to the "vimConnectionInfo" attribute of "VnfInstance" + according to the rules of JSON Merge Patch (see IETF RFC 7396 + [5]). + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines the + structure of the "interfaceInfo" and "accessInfo" + attributes, based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values is + expected to change over time as new types or versions of + VIMs become available. The ETSI NFV registry of + VIM-related information provides access to information + about VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The structure of + the registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + localizationLanguage: + description: | + A string defined in IETF RFC 8259. + type: string + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + selectedDeployableModule: + description: > + Identifier of a selected deployable module. Only VNFCs based + on VDUs that belong to deployable modules listed in this + attribute are requested to be instantiated. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + resourceCapacityDefinition: + description: > + Indicates values for resource capacity related attributes + pertaining to a descriptor. Values can only be provided for + resource capacity related attributes that have been defined + in the VNFD as being configurable. Furthermore, provided + values shall be within the allowed values indicated in the + VNFD. + type: array + items: + description: > + This type represents selected values for capacity related + VDU attributes. + + * NOTE: Resource definitions not related to a VDU are not + considered in this version of the present document. + type: object + required: + - type + properties: + tag: + description: > + Tag assigned by the issuer of a VNF LCM operation + request that contains this data type with values to be + applied to a VDU. It is used for tracking purposes. + + The tag is preserved in the run time record as long as + at least one value of the capacity related attributes + associated with that tag is still valid, i.e., it has + not been modified by a later VNF LCM operation request. + + At most one tag can be included when the data type is + used in a VNF LCM operation request. + + When the data type is used in the VnfInstance data type + it may contain multiple tags, namely those provided in + VNF LCM requests, if at least one of the values provided + in that request associated to that tag is still + applicable in the VNFCs created from this VDU, i.e., it + has not been modified by a later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: | + Type of the resource definition referenced. + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + osContainerDescData: + description: > + Indicates values for resource capacity related + attributes in an OsContainerDesc. It shall be present + when the attribute 'type' indicates OSCONTAINER and + absent otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of an OsContainer resource. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for the + container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for the + container expressed in the same units as + specified in the + requested_memory_resources_valid_values property + in VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 + [14]) for this container descriptor. See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources of the + type indicated in the key. The key is a string + that identifies an extended resource indicated in + the extended_resource_requests property in the + VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) + for this container descriptor. The value is an + integer that indicates the required amount for a + particular extended resource. See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container can + maximally use in milli-CPU. See note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required for all the + hugepages of the size indicated in the key. The + key is a string and corresponds to one of the + values of the hugepage sizes indicated in the + huge_pages_resources property in the VNFD (clause + 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this + container descriptor. The value is a number that + indicates the required total size expressed in the + same units as in the huge_pages_resource property + in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 + [14]) that indicates the valid values for required + total size for the particular hugepage size. See + note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores are + requested to be allocated to logical CPU cores + according to the cpuOperationalPowerStates + attribute. In case of "DYNAMIC", the CPU power + states of virtual CPU cores can be allocated + to logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual compute resource + of a VM. + + * NOTE: At least one of the attributes shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required for all the + hugepages of the size indicated in the key. The key + is a string and corresponds to one of the values of + the hugepage sizes indicated in the + huge_pages_requirements property in the VNFD (clause + 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for this + virtual compute descriptor. The value is a + numberthat indicates the required total size + expressed in the same units as in the + huge_pages_requirements property in the VNFD (clause + 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) that indicates + the valid vaues for required total size for the + particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores are + requested to be allocated to logical CPU cores + according to the cpuOperationalPowerStates + attribute. In case of "DYNAMIC", the CPU power + states of virtual CPU cores can be allocated to + logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size related + attribute in an VirtualStorageDesc. It shall be present + when the attribute 'type' indicates STORAGE and absent + otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual storage + resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + required: true + ScaleVnfRequest: + description: Parameters for the scale VNF operation. + content: + application/json: + schema: + description: > + This type represents request parameters for the "Scale VNF" + operation. + type: object + required: + - type + properties: + type: + description: > + Indicates the type of the scale operation requested. Permitted + values: * SCALE_OUT: adding additional VNFC instances to the + VNF to increase + capacity + * SCALE_IN: removing VNFC instances from the VNF in order to + release + unused capacity. + * SCALE_VERTICAL: increasing or decreasing the resource + capacity of all instances of one or multiple VNFCs. + type: string + enum: + - SCALE_OUT + - SCALE_IN + - SCALE_VERTICAL + aspectId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + numberOfSteps: + description: > + Number of scaling steps to be executed as part of this Scale + VNF operation. It shall be a positive number and the default + value shall be 1. + type: integer + default: 1 + resourceCapacityDefinition: + description: > + Indicates values for resource capacity related attributes + pertaining to a descriptor. The indicated values are absolute + (target) values, as opposed to relative (delta) values. + Values can only be provided for resource capacity related + attributes that have been defined in the VNFD as being + configurable. Furthermore, provided values shall be within the + allowed values indicated in the VNFD. It shall be present + when 'type' indicates SCALE_VERTICAL and absent otherwise. + type: array + items: + description: > + This type represents selected values for capacity related + VDU attributes. + + * NOTE: Resource definitions not related to a VDU are not + considered in this version of the present document. + type: object + required: + - type + properties: + tag: + description: > + Tag assigned by the issuer of a VNF LCM operation + request that contains this data type with values to be + applied to a VDU. It is used for tracking purposes. + + The tag is preserved in the run time record as long as + at least one value of the capacity related attributes + associated with that tag is still valid, i.e., it has + not been modified by a later VNF LCM operation request. + + At most one tag can be included when the data type is + used in a VNF LCM operation request. + + When the data type is used in the VnfInstance data type + it may contain multiple tags, namely those provided in + VNF LCM requests, if at least one of the values provided + in that request associated to that tag is still + applicable in the VNFCs created from this VDU, i.e., it + has not been modified by a later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: | + Type of the resource definition referenced. + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + osContainerDescData: + description: > + Indicates values for resource capacity related + attributes in an OsContainerDesc. It shall be present + when the attribute 'type' indicates OSCONTAINER and + absent otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of an OsContainer resource. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for the + container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for the + container expressed in the same units as + specified in the + requested_memory_resources_valid_values property + in VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 + [14]) for this container descriptor. See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources of the + type indicated in the key. The key is a string + that identifies an extended resource indicated in + the extended_resource_requests property in the + VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) + for this container descriptor. The value is an + integer that indicates the required amount for a + particular extended resource. See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container can + maximally use in milli-CPU. See note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required for all the + hugepages of the size indicated in the key. The + key is a string and corresponds to one of the + values of the hugepage sizes indicated in the + huge_pages_resources property in the VNFD (clause + 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this + container descriptor. The value is a number that + indicates the required total size expressed in the + same units as in the huge_pages_resource property + in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 + [14]) that indicates the valid values for required + total size for the particular hugepage size. See + note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores are + requested to be allocated to logical CPU cores + according to the cpuOperationalPowerStates + attribute. In case of "DYNAMIC", the CPU power + states of virtual CPU cores can be allocated + to logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual compute resource + of a VM. + + * NOTE: At least one of the attributes shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required for all the + hugepages of the size indicated in the key. The key + is a string and corresponds to one of the values of + the hugepage sizes indicated in the + huge_pages_requirements property in the VNFD (clause + 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for this + virtual compute descriptor. The value is a + numberthat indicates the required total size + expressed in the same units as in the + huge_pages_requirements property in the VNFD (clause + 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) that indicates + the valid vaues for required total size for the + particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores are + requested to be allocated to logical CPU cores + according to the cpuOperationalPowerStates + attribute. In case of "DYNAMIC", the CPU power + states of virtual CPU cores can be allocated to + logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size related + attribute in an VirtualStorageDesc. It shall be present + when the attribute 'type' indicates STORAGE and absent + otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual storage + resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + required: true + ScaleVnfToLevelRequest: + description: Parameters for the scale VNF to Level operation. + content: + application/json: + schema: + description: "This type represents request parameters for the \"Scale VNF to Level\" operation.\nNOTE 1:\tEither the instantiationLevelId attribute or the scaleInfo attribute or the powerProfileId attribute shall \n be included, but not multiple of them.\nNOTE 2: If the referenced instantiationLevel, the scaleInfo or powerProfileId attribute contain information related to VNFCs \n that are not going to be instantiated due to the selection of deployable modules, the information is stored in the \n VNFM for later use and included in the instantiatedVnfInfo. If, during the lifecycle of the VNF, as a result of a \n change of the selected deployable modules any of those VNFCs is going to be instantiated, the stored information \n determines the number of instances, unless the request that triggered the change also contains information \n about the number of instances\n" + type: object + anyOf: + - oneOf: + - required: + - instantiationLevelId + - required: + - scaleInfo + - required: + - powerProfileId + properties: + instantiationLevelId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + scaleInfo: + description: > + For each scaling aspect of the current deployment flavour, + indicates the target scale level to which the VNF is to be + scaled. See notes 1 and 2. + type: array + items: + description: > + This type represents the scale level of a VNF instance + related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being globally + unique. + type: string + powerProfileId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + required: true + ChangeVnfFlavourRequest: + description: Parameters for the Change VNF Flavour operation. + content: + application/json: + schema: + description: "This type represents request parameters for the \"Change VNF flavour\" operation.\n* NOTE 1:\tThe indication of externally-managed internal VLs is needed in case networks \n have been pre-configured for use with certain VNFs, for instance to ensure \n that these networks have certain properties such as security or acceleration \n features, or to address particular network topologies. The present document \n assumes that externally-managed internal VLs are managed by the NFVO and created \n towards the VIM.\n* NOTE 2:\tIt is possible to have several ExtManagedVirtualLinkData for the same VNF internal \n VL in case of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkData \n corresponding to the same VNF internal VL shall indicate so by referencing to the same \n VnfVirtualLinkDesc and externally-managed multi-site VL instance (refer to clause 4.4.1.12).\n* NOTE 3: The target size for VNF instantiation may be specified in either instantiationLevelId or targetScaleLevelInfo, but\n not both. If none of the two attributes (instantiationLevelId or targetScaleLevelInfo) are present, the default\n instantiation level as declared in the VNFD shall be used.\n* NOTE 4: If targetScaleLevelInfo is specified, information provided in targetScaleLevelInfo shall be used for instantiating\n scalable constituents of the VNF (e.g, VDUs/VLs). For scaling aspects not specified in targetScaleLevelInfo or\n for the VNF constituents (e.g.,VDUs/VLs) that are not scalable, the default instantiation level as declared in the\n VNFD shall be used for instantiation.\n" + type: object + required: + - newFlavourId + properties: + newFlavourId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + instantiationLevelId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + targetScaleLevelInfo: + description: > + This attribute is applicable if VNF supports target scale + level instantiation. For each scaling aspect of the current + deployment flavour, the attribute specifies the scale level of + VNF constituents (e.g., VDU level) to be instantiated. See + notes 3 and 4. + type: array + items: + description: > + This type represents the scale level of a VNF instance + related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being globally + unique. + type: string + extVirtualLinks: + description: > + Information about external VLs to connect the VNF to, + including configuration information for the CPs via which the + VNF instance can attach to this VL. Entries in the list of + external VLs that are unchanged need not be supplied as part + of this request. The following applies to the + "ExtVirtualLinkData" information provided in this request, + together with the related "ExtVirtualLinkInfo" information + known to the VNFM represented in the "VnfInstance" structure + (see clause 5.5.2.2) and the related overriding information + provided in the "Grant" structure (see clause 9.5.2.3): Even + if the VNF is not in fully scaled-out state after changing + the flavour, the API consumer shall provide enough CP + configuration records to allow connecting the VNF instance, + fully scaled out in all scaling aspects, to the external VLs. + type: array + items: + description: "This type represents an external VL.\n* NOTE 1:\tA link port is not needed for an external CP instance that exposes a CP in the following cases:\n 1) For a VIP CP directly exposed as an external CP:\n 1.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD.\n 1.2) A dedicated IP address is allocated as VIP address, but the NFVO indicates that no port is needed\n (createExtLinkPort in VnfExtCpConfig set to false).\n 2) For a VIP CP exposed as an external CP via a floating IP address:\n 2.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD, and the VNFC CP\n associated to the VIP CP is also exposed via a floating IP address.\n 3) For a VIRTUAL CP exposed as an external CP.\n 4) For a VNFC CP exposed as an external CP in a secondary container cluster external network or a\n secondary container cluster internal network.\n\n* NOTE 2: An example of the network attachment definition resource when the container infrastructure service\n management is a Kubernetes® instance is a network attachment definition (NAD).\n* NOTE 3: Either \"extCps\" or “extCpsDeletion\" shall be present, but not both.\n" + type: object + required: + - id + - resourceId + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + extCps: + description: > + External CPs of the VNF to be connected to this external + VL. Entries in the list of external CP data that are + unchanged need not be supplied if the ExtVirtualLinkData + structure is part of a request or response that modifies + the external connectivity. See note 3. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. + + The entries shall be applied by the VNFM according + to the rules of JSON Merge Patch (see IETF RFC + 7396). See notes 2, 3, 4, 5, 6. In case of + deleting an external CP, the list of instances to + be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extLinkPorts: + description: > + Externally provided link ports to be used to connect + external connection points to this external VL. If this + attribute is not present, the VNFM shall create the link + ports on the external VL except in the cases defined + below. See note 1. + type: array + items: + description: "This type represents an externally provided link port to be used to connect an external connection point to an external VL. * NOTE:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + extNetAttDefResourceData: + description: > + Externally provided network attachment definition + resource(s) that provide the specification of the + interface to attach external CPs to this external VL. + See note 2. It is only applicable if the external VL is + realized by a secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + This type represents a network attachment definition + resource that provides the specification of the + interface to be used to connect one or multiple + connection points to a secondary container cluster + network realizing a VL. + type: object + required: + - netAttDefResourceId + - resourceHandle + properties: + netAttDefResourceId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + extCpsDeletion: + description: > + External CPs of the VNF to be disconnected from this + external VL and to be deleted. See note 3. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. + + The entries shall be applied by the VNFM according + to the rules of JSON Merge Patch (see IETF RFC + 7396). See notes 2, 3, 4, 5, 6. In case of + deleting an external CP, the list of instances to + be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extManagedVirtualLinks: + description: > + Information about internal VLs that are managed by the NFVO. + See notes 1 and 2. + type: array + items: + description: > + This type represents an externally-managed internal VL. + + * NOTE 1: It is only applicable if the externally-managed VL + is realized by a secondary container cluster network. It + shall + not be present otherwise. + * NOTE 2: A link port is not needed for a VNFC internal + connection point connected to a secondary container cluster + network. + * NOTE 3: An example of the network attachment definition + resource when the container infrastructure service + management is a Kubernetes® instance is a network attachment definition (NAD). + + * NOTE 4: In the case that the cloud native template + included in the MCIOP describes the set of VNFC instances, + an + instance of intCp need not be included for each VNFC instance as all instances would contain the same + information. It is sufficient to include one intCp for the related CPD. The case of using, for a scalable VDU, a + cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present + document version + * NOTE 5: Both "vnfLinkPort" and "netAttDefResource" + attributes can be provided in a "ExtManagedVirtualLinkData" + to indicate + that a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs + type: object + required: + - id + - vnfVirtualLinkDescId + - resourceId + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfVirtualLinkDescId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + netAttDefResourceData: + description: > + Externally provided network attachment definition + resource(s) that provide the specification of the + interface to attach VNFC connection points to this + externallymanaged VL. See notes 1, 3 and 5. + type: array + items: + description: > + This type represents a network attachment definition + resource that provides the specification of the + interface to be used to connect one or multiple + connection points to a secondary container cluster + network realizing a VL. + type: object + required: + - netAttDefResourceId + - resourceHandle + properties: + netAttDefResourceId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + intCp: + description: > + Internal CPs of the VNF to be connected to this + externally-managed VL. See note 1 and 4. + type: array + items: + description: > + This type represents input information related to one + or more VNF internal CP instances created based on the + same CPD. + + NOTE: Cardinality greater than 1 is only applicable + for specific cases where more than one network + attachment + definition resource is needed to fulfil the connectivity requirements of the VNF internal CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall + belong to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + type: object + required: + - cpdId + - netAttDefResourceId + properties: + cpdId: + description: > + An identifier with the intention of being globally + unique. + type: string + netAttDefResourceId: + description: > + Identifiers of the “NetAttDefResourceData” + structure that provides the specification of the + interface to attach the VNF internal CP created + from the CPD identified by cpdId to a secondary + container cluster network. See note. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfLinkPort: + description: > + Externally provided link ports to be used to connect + VNFC connection points to this externally-managed VL on + this network resource. If this attribute is not present, + the VNFM shall create the link ports on the + externally-managed VL. See notes 2 and 5. + type: array + items: + description: > + This type represents an externally provided link port + to be used to connect a VNFC connection point to an + externally managed VL. + type: object + required: + - vnfLinkPortId + - resourceHandle + properties: + vnfLinkPortId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + extManagedMultisiteVirtualLinkId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimConnectionInfo: + description: > + Information about VIM or CISM connections to be used for + managing the resources for the VNF instance, or refer to + external/externally-managed virtual links. This attribute + shall only be supported and may be present if - the resources + for at least one of the VNFCs shall be managed by a VIM and + VNF-related resource management in direct mode is applicable. + - the resources for at least one of the VNFCs shall be managed + by a CISM. The VNFM shall apply the content of this attribute + to the "vimConnectionInfo" attribute of "VnfInstance" + according to the rules of JSON Merge Patch (see IETF RFC 7396 + [5]). + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines the + structure of the "interfaceInfo" and "accessInfo" + attributes, based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values is + expected to change over time as new types or versions of + VIMs become available. The ETSI NFV registry of + VIM-related information provides access to information + about VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The structure of + the registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + selectedDeployableModule: + description: > + Identifier of a selected deployable module. Only VNFCs based + on VDUs that belong to deployable modules listed in this + attribute are requested to be instantiated or preserved if + they were already instantiated. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + resourceCapacityDefinition: + description: > + Indicates values for resource capacity related attributes + pertaining to a descriptor. Values can only be provided for + resource capacity related attributes that have been defined + in the VNFD as being configurable. Furthermore, provided + values shall be within the allowed values indicated in the + VNFD. + type: array + items: + description: > + This type represents selected values for capacity related + VDU attributes. + + * NOTE: Resource definitions not related to a VDU are not + considered in this version of the present document. + type: object + required: + - type + properties: + tag: + description: > + Tag assigned by the issuer of a VNF LCM operation + request that contains this data type with values to be + applied to a VDU. It is used for tracking purposes. + + The tag is preserved in the run time record as long as + at least one value of the capacity related attributes + associated with that tag is still valid, i.e., it has + not been modified by a later VNF LCM operation request. + + At most one tag can be included when the data type is + used in a VNF LCM operation request. + + When the data type is used in the VnfInstance data type + it may contain multiple tags, namely those provided in + VNF LCM requests, if at least one of the values provided + in that request associated to that tag is still + applicable in the VNFCs created from this VDU, i.e., it + has not been modified by a later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: | + Type of the resource definition referenced. + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + osContainerDescData: + description: > + Indicates values for resource capacity related + attributes in an OsContainerDesc. It shall be present + when the attribute 'type' indicates OSCONTAINER and + absent otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of an OsContainer resource. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for the + container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for the + container expressed in the same units as + specified in the + requested_memory_resources_valid_values property + in VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 + [14]) for this container descriptor. See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources of the + type indicated in the key. The key is a string + that identifies an extended resource indicated in + the extended_resource_requests property in the + VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) + for this container descriptor. The value is an + integer that indicates the required amount for a + particular extended resource. See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container can + maximally use in milli-CPU. See note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required for all the + hugepages of the size indicated in the key. The + key is a string and corresponds to one of the + values of the hugepage sizes indicated in the + huge_pages_resources property in the VNFD (clause + 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this + container descriptor. The value is a number that + indicates the required total size expressed in the + same units as in the huge_pages_resource property + in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 + [14]) that indicates the valid values for required + total size for the particular hugepage size. See + note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores are + requested to be allocated to logical CPU cores + according to the cpuOperationalPowerStates + attribute. In case of "DYNAMIC", the CPU power + states of virtual CPU cores can be allocated + to logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual compute resource + of a VM. + + * NOTE: At least one of the attributes shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required for all the + hugepages of the size indicated in the key. The key + is a string and corresponds to one of the values of + the hugepage sizes indicated in the + huge_pages_requirements property in the VNFD (clause + 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for this + virtual compute descriptor. The value is a + numberthat indicates the required total size + expressed in the same units as in the + huge_pages_requirements property in the VNFD (clause + 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) that indicates + the valid vaues for required total size for the + particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores are + requested to be allocated to logical CPU cores + according to the cpuOperationalPowerStates + attribute. In case of "DYNAMIC", the CPU power + states of virtual CPU cores can be allocated to + logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size related + attribute in an VirtualStorageDesc. It shall be present + when the attribute 'type' indicates STORAGE and absent + otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual storage + resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + certificateConfigurationData: + description: > + This type provides input information related to certificate + management. + + ETSI GS NFV-SOL 009 [i.18] specifies the means to discover the + applicable certificate management mode of VNFM and configure + into the NFVO applicable certificate management mode via the + "NFV-MANO Configuration and Information Management" interface + type: object + properties: + overridingCertificateProfiles: + description: > + Overriding certificate profile. This overrides the + certificateBaseProfile provided in the VNFD, and the CA + and CMF can additionally override aspects of this + certificateBaseProfile at later point in the VNF lifecycle + if necessary to meet operator security policy. + type: array + items: + description: > + NOTE: At least one overriding attributes shall be + present, otherwise shall be absent. + + This type provides input information to override + certificate base profile for certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + issuer: + description: Issuer of certificates. See note. + type: string + issuerUniqueIdentifier: + description: > + An identifier with the intention of being globally + unique. + type: string + subject: + description: > + This type provides input information related to the + subject of the certificate. + + NOTE: At least one overriding attributes shall be + present, otherwise shall be absent. + type: object + properties: + commonName: + description: > + Information of the certification target subject + FQDN. Can be set empty when this certificate is + used for encrypted communication using IP + address. See note. + type: string + organization: + description: >- + Information of the certification target subject + Organization. See note. + type: string + country: + description: >- + Information of the certification target subject + Country. See note. + type: string + state: + description: >- + Information of the certification target subject + State. See note. + type: string + locality: + description: >- + Information of the certification target subject + Locality. See note. + type: string + emailAddress: + description: >- + Information of the certification contact email + address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of being globally + unique. + type: string + basicConstraints: + description: Basic constraints of certificates. See note. + type: string + issuerAltName: + description: >- + Alternative name of issuer of certificates in this + NS. See note. + type: array + items: + type: string + subjectAltName: + description: > + Alternative name of subject of certificates. Shall + be present when this certificate is used for + encrypted communication using IP address and + subjectAltName attribute of CertificateBaseProfile + in CertificateDesc of VNFD is empty (see ETSI GS + NFV-IFA 011 [14], clause 7.1.19.4). See note. + type: array + items: + type: string + nameConstraints: + description: Name constraints of certificates. See note. + type: array + items: + type: string + securityPolicy: + description: | + Security policy to be satisfied for the certificate. + type: array + items: + description: > + This type provides input information related to security + policy for certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + maxValidityPeriod: + description: Allowed max validity period for certificates. + type: number + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: number + cmfData: + description: > + This type provides input information related to CMF for + certificate management. + type: object + required: + - endPoint + - supportedProtocols + properties: + endPoint: + description: End point of CMF instance. + type: object + properties: + 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 + link: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + supportedProtocols: + description: Supported protocols by CMF instance. + type: array + items: + description: Supported protocol by CMF instance. + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + required: true + TerminateVnfRequest: + description: Parameters for the VNF termination. + content: + application/json: + schema: + description: "This type represents request parameters for the \"Terminate VNF\" operation.\nNOTE:\tIf the VNF is still in service, requesting forceful termination can \n adversely impact network service.\n" + type: object + required: + - terminationType + properties: + terminationType: + description: > + Indicates whether forceful or graceful termination is + requested. See note. + + Permitted values: - FORCEFUL: The VNFM will shut down the VNF + and release the + resources immediately after accepting the request. + - GRACEFUL: The VNFM will first arrange to take the VNF out of + service after accepting the request. Once the operation + of taking the VNF out of service finishes (irrespective + of whether it has succeeded or failed) or once the timer + value specified in the "gracefulTerminationTimeout" + attribute expires, the VNFM will shut down the VNF and + release the resources. + type: string + enum: + - FORCEFUL + - GRACEFUL + gracefulTerminationTimeout: + description: > + This attribute is only applicable in case of graceful + termination. It defines the time to wait for the VNF to be + taken out of service before shutting down the VNF and + releasing the resources. The unit is seconds. If not given and + the "terminationType" attribute is set to "GRACEFUL", it is + expected that the VNFM waits for the successful taking out of + service of the VNF, no matter how long it takes, before + shutting down the VNF and releasing the resources. + type: integer + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + required: true + HealVnfRequest: + description: Parameters for the Heal VNF operation. + content: + application/json: + schema: + type: object + properties: + cause: + description: | + A string defined in IETF RFC 8259. + type: string + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + healingResource: + description: > + Indicates the kinds of the virtual resource to be healed. + + Permitted values: + * VL + * LINKPORT + * STORAGE + * VIRTUALCP + * COMPUTE + * OSCONTAINER + + Default value is COMPUTE when the VDUs of the VNF are realized + by a set of virtual machines and OSCONTAINER when the VDUs of + the VNF are realized by a set of OS containers. + type: array + enum: + - VL + - LINKPORT + - STORAGE + - VIRTUALCP + - COMPUTE + - OSCONTAINER + required: true + OperateVnfRequest: + description: Parameters for the Operate VNF operation. + content: + application/json: + schema: + description: "This type represents request parameters for the \"Operate VNF\" operation.\nNOTE:\tThe \"stopType\" and \"gracefulStopTimeout\" attributes shall be absent, \n when the \"changeStateTo\" attribute is equal to \"STARTED\". \n The \"gracefulStopTimeout\" attribute shall be present, when the \"changeStateTo\" \n is equal to \"STOPPED\" and the \"stopType\" attribute is equal to \"GRACEFUL\". \n The \"gracefulStopTimeout\" attribute shall be absent, when the \"changeStateTo\" \n attribute is equal to \"STOPPED\" and the \"stopType\" attribute is equal to \"FORCEFUL\". \n The request shall be treated as if the \"stopType\" attribute has been set to \"FORCEFUL\", \n when the \"changeStateTo\" attribute is equal to \"STOPPED\" and the \"stopType\" attribute \n is absent.\n" + required: + - changeStateTo + properties: + changeStateTo: + description: > + STARTED: The VNF instance is up and running. STOPPED: The VNF + instance has been shut down. + type: string + enum: + - STARTED + - STOPPED + stopType: + description: > + * FORCEFUL: The VNFM will stop the VNF instance immediately + after accepting + the request. + * GRACEFUL: The VNFM instance will first arrange to take the + VNF out of + service after accepting the request. Once that operation is successful + or once the timer value specified in the "gracefulStopTimeout" attribute + expires, the VNFM will stop the VNF instance. + type: string + enum: + - FORCEFUL + - GRACEFUL + gracefulStopTimeout: + description: > + The time interval (in seconds) to wait for the VNF to be taken + out of service during graceful stop, before stopping the VNF. + See note. + type: integer + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + required: true + ChangeExtVnfConnectivityRequest: + description: | + Parameters for the Change external VNF connectivity operation. + content: + application/json: + schema: + description: > + This type represents request parameters for the "Change external + VNF connectivity" operation to modify the external connectivity of + a VNF instance. The following behaviour applies for the changes + that can be performed with this operation: + To change the connection of external CP instances based on certain external CPDs from a "source" external + VL to a different "target" external VL, the identifier of the "target" external VL shall be sent in the + "extVirtualLinkId" attribute of the "extVirtualLinks" parameter, and the "extCps" attributes of that parameter + shall refer via the "cpdId" attribute to the external CPDs of the corresponding external connection point + instances that are to be reconnected to the target external VL. + + * NOTE 1: For CP instances that are not part of a trunk this means + that all CP instances based on a given external + CPD will be reconnected. See clause B.3.3 for an illustration. Likewise, for CP instances that are part of a + trunk and have the same segmentationId, all CP instances (subports) based on a given external CPD will + be connected, disconnected or reconnected. + + To change the connectivity parameters of the external CPs connected to a particular external VL, including + changing addresses, the identifier of that external VL shall be sent in the "extVirtualLinkId" attribute of the + "extVirtualLinks" parameter, and the "extCps" attribute of that parameter shall contain at least those entries + with modified parameters. + + To create a new external CP instance, this shall be based on a certain external CPD that is referenced by at + least a VDU from which the VNF instance has at least one VNFC instantiated. The newly external CP instance + connects to the same external VL as other CP instances created based on the same CPD. For creating a new + external CP instance: + The "extVirtualLinkId" attribute of the "extVirtualLinks" parameter indicates the identifier of the + external VL instance to which the new external CP instance is requested to be connected (refer to + above behavior). + + The "extCps" attribute shall refer via the "cpdId" attribute to the external CPDs from which a new + instance is to be created. + + * NOTE 2: For the capability to connect to different external VLs, + refer to the use of subports. + To delete an existing external CP instance: + The "extVirtualLinkId" attribute of the "extVirtualLinks" parameter indicates the identifier of the + external VL instance from which the existing external CP instance is requested to be disconnected. + + The "extCpsDeletion" attribute shall refer via the "cpdId" attribute to the external CPD from which a + corresponding CP instance will be deleted. + + The " parentCpConfigId" of the contained "cpConfig" in the "extCps" shall refer to the particular + external CP instance to be deleted. + + * NOTE 3: If external CPs are requested to be created and + connected, and disconnected and deleted in a same + operation request, the consumer can provide respective "extVirtualLinks", e.g., one for the external CPs + to be created and connected, and one for the external CPs to disconnect and delete. + type: object + required: + - extVirtualLinks + properties: + extVirtualLinks: + description: > + Information about external VLs to change (e.g. connect the VNF + to) including configuration information for the CPs via which + the VNF instance can attach to this VL. Entries in the list of + external VLs that are unchanged need not be supplied as part + of this request. The following applies to the + "ExtVirtualLinkData" information provided in this request, + together with the related "ExtVirtualLinkInfo" + informationknown to the VNFM represented in the "VnfInstance" + structure (see clause 5.5.2.2) and the related overriding + information provided in the "Grant" structure (see clause + 9.5.2.3): Even if the VNF is not in fully scaled-out state, + the API consumer shall provide enough CP configuration + records to allow connecting the VNF instance, fully scaled out + in all scaling aspects, to the external VLs. + type: array + items: + description: "This type represents an external VL.\n* NOTE 1:\tA link port is not needed for an external CP instance that exposes a CP in the following cases:\n 1) For a VIP CP directly exposed as an external CP:\n 1.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD.\n 1.2) A dedicated IP address is allocated as VIP address, but the NFVO indicates that no port is needed\n (createExtLinkPort in VnfExtCpConfig set to false).\n 2) For a VIP CP exposed as an external CP via a floating IP address:\n 2.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD, and the VNFC CP\n associated to the VIP CP is also exposed via a floating IP address.\n 3) For a VIRTUAL CP exposed as an external CP.\n 4) For a VNFC CP exposed as an external CP in a secondary container cluster external network or a\n secondary container cluster internal network.\n\n* NOTE 2: An example of the network attachment definition resource when the container infrastructure service\n management is a Kubernetes® instance is a network attachment definition (NAD).\n* NOTE 3: Either \"extCps\" or “extCpsDeletion\" shall be present, but not both.\n" + type: object + required: + - id + - resourceId + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + extCps: + description: > + External CPs of the VNF to be connected to this external + VL. Entries in the list of external CP data that are + unchanged need not be supplied if the ExtVirtualLinkData + structure is part of a request or response that modifies + the external connectivity. See note 3. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. + + The entries shall be applied by the VNFM according + to the rules of JSON Merge Patch (see IETF RFC + 7396). See notes 2, 3, 4, 5, 6. In case of + deleting an external CP, the list of instances to + be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extLinkPorts: + description: > + Externally provided link ports to be used to connect + external connection points to this external VL. If this + attribute is not present, the VNFM shall create the link + ports on the external VL except in the cases defined + below. See note 1. + type: array + items: + description: "This type represents an externally provided link port to be used to connect an external connection point to an external VL. * NOTE:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + extNetAttDefResourceData: + description: > + Externally provided network attachment definition + resource(s) that provide the specification of the + interface to attach external CPs to this external VL. + See note 2. It is only applicable if the external VL is + realized by a secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + This type represents a network attachment definition + resource that provides the specification of the + interface to be used to connect one or multiple + connection points to a secondary container cluster + network realizing a VL. + type: object + required: + - netAttDefResourceId + - resourceHandle + properties: + netAttDefResourceId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + extCpsDeletion: + description: > + External CPs of the VNF to be disconnected from this + external VL and to be deleted. See note 3. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. + + The entries shall be applied by the VNFM according + to the rules of JSON Merge Patch (see IETF RFC + 7396). See notes 2, 3, 4, 5, 6. In case of + deleting an external CP, the list of instances to + be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + vimConnectionInfo: + description: > + Information about VIM or CISM connections to be used for + managing the resources for the VNF instance, or refer to + external virtual links. This attribute shall only be supported + and may be present if + - the resources for at least one of the VNFCs + shall be managed by a VIM and VNF-related + resource management in direct mode is + applicable. + - the resources for at least one of the VNFCs + shall be managed by a CISM. + The VNFM shall apply the content of this attribute to the + "vimConnectionInfo" attribute of "VnfInstance" according to + the rules of JSON Merge Patch (see IETF RFC 7396 [5]). + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines the + structure of the "interfaceInfo" and "accessInfo" + attributes, based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values is + expected to change over time as new types or versions of + VIMs become available. The ETSI NFV registry of + VIM-related information provides access to information + about VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The structure of + the registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + certificateConfigurationData: + description: > + This type provides input information related to certificate + management. + + ETSI GS NFV-SOL 009 [i.18] specifies the means to discover the + applicable certificate management mode of VNFM and configure + into the NFVO applicable certificate management mode via the + "NFV-MANO Configuration and Information Management" interface + type: object + properties: + overridingCertificateProfiles: + description: > + Overriding certificate profile. This overrides the + certificateBaseProfile provided in the VNFD, and the CA + and CMF can additionally override aspects of this + certificateBaseProfile at later point in the VNF lifecycle + if necessary to meet operator security policy. + type: array + items: + description: > + NOTE: At least one overriding attributes shall be + present, otherwise shall be absent. + + This type provides input information to override + certificate base profile for certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + issuer: + description: Issuer of certificates. See note. + type: string + issuerUniqueIdentifier: + description: > + An identifier with the intention of being globally + unique. + type: string + subject: + description: > + This type provides input information related to the + subject of the certificate. + + NOTE: At least one overriding attributes shall be + present, otherwise shall be absent. + type: object + properties: + commonName: + description: > + Information of the certification target subject + FQDN. Can be set empty when this certificate is + used for encrypted communication using IP + address. See note. + type: string + organization: + description: >- + Information of the certification target subject + Organization. See note. + type: string + country: + description: >- + Information of the certification target subject + Country. See note. + type: string + state: + description: >- + Information of the certification target subject + State. See note. + type: string + locality: + description: >- + Information of the certification target subject + Locality. See note. + type: string + emailAddress: + description: >- + Information of the certification contact email + address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of being globally + unique. + type: string + basicConstraints: + description: Basic constraints of certificates. See note. + type: string + issuerAltName: + description: >- + Alternative name of issuer of certificates in this + NS. See note. + type: array + items: + type: string + subjectAltName: + description: > + Alternative name of subject of certificates. Shall + be present when this certificate is used for + encrypted communication using IP address and + subjectAltName attribute of CertificateBaseProfile + in CertificateDesc of VNFD is empty (see ETSI GS + NFV-IFA 011 [14], clause 7.1.19.4). See note. + type: array + items: + type: string + nameConstraints: + description: Name constraints of certificates. See note. + type: array + items: + type: string + securityPolicy: + description: | + Security policy to be satisfied for the certificate. + type: array + items: + description: > + This type provides input information related to security + policy for certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + maxValidityPeriod: + description: Allowed max validity period for certificates. + type: number + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: number + cmfData: + description: > + This type provides input information related to CMF for + certificate management. + type: object + required: + - endPoint + - supportedProtocols + properties: + endPoint: + description: End point of CMF instance. + type: object + properties: + 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 + link: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + supportedProtocols: + description: Supported protocols by CMF instance. + type: array + items: + description: Supported protocol by CMF instance. + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + required: true + ChangeCurrentVnfPkgRequest: + description: > + Parameters for the Change current VNF package operation, as defined in + clause 5.5.2.11a. + content: + application/json: + schema: + description: "This type represents request parameters for the \"Change current VNF package\" operation to replace the VNF package on which a VNF instance is based.\nNOTE 1:\tThe indication of externally-managed internal VLs is needed in case networks \n have been pre-configured for use with certain VNFs, for instance to ensure \n that these networks have certain properties such as security or acceleration \n features, or to address particular network topologies. The present document \n assumes that externally-managed internal VLs are managed by the NFVO and created \n towards the VIM.\nNOTE 2:\tIt is possible to have several ExtManagedVirtualLinkData for the same VNF internal \n VL in case of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkData \n corresponding to the same VNF internal VL shall indicate so by referencing to the same \n VnfVirtualLinkDesc and externally-managed multi-site VL instance (refer to clause 4.4.1.12).\nNOTE 3: Component mappings are defined in the VNFD in the source or destination package for the relevant change \n path. See clause 7.1.15.2 in ETSI GS NFV-IFA 011 [13].\nNOTE 4: In the current version of the present document, only Rolling upgrade and Blue-green \n upgrade types are supported. The definition of additional upgrade types is left for future \n specification.\n" + type: object + required: + - vnfdId + properties: + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + extVirtualLinks: + description: > + Information about external VLs to connect the VNF to, + including configuration information for the CPs via which the + VNF instance can attach to this VL. Entries in the list that + are unchanged need not be supplied as part of this request. + The following applies to the "ExtVirtualLinkData" information + provided in this request, together with the related + "ExtVirtualLinkInfo" information known to the VNFM represented + in the "VnfInstance" structure (see clause 5.5.2.2) and the + related overriding information provided in the "Grant" + structure (see clause 9.5.2.3): Even if the VNF is not in + fully scaled-out state after the change of the VNF package, + the API consumer shall provide enough CP configuration records + to allow connecting the VNF instance, fully scaled out in all + scaling aspects, to the external VLs. + type: array + items: + description: "This type represents an external VL.\n* NOTE 1:\tA link port is not needed for an external CP instance that exposes a CP in the following cases:\n 1) For a VIP CP directly exposed as an external CP:\n 1.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD.\n 1.2) A dedicated IP address is allocated as VIP address, but the NFVO indicates that no port is needed\n (createExtLinkPort in VnfExtCpConfig set to false).\n 2) For a VIP CP exposed as an external CP via a floating IP address:\n 2.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD, and the VNFC CP\n associated to the VIP CP is also exposed via a floating IP address.\n 3) For a VIRTUAL CP exposed as an external CP.\n 4) For a VNFC CP exposed as an external CP in a secondary container cluster external network or a\n secondary container cluster internal network.\n\n* NOTE 2: An example of the network attachment definition resource when the container infrastructure service\n management is a Kubernetes® instance is a network attachment definition (NAD).\n* NOTE 3: Either \"extCps\" or “extCpsDeletion\" shall be present, but not both.\n" + type: object + required: + - id + - resourceId + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + extCps: + description: > + External CPs of the VNF to be connected to this external + VL. Entries in the list of external CP data that are + unchanged need not be supplied if the ExtVirtualLinkData + structure is part of a request or response that modifies + the external connectivity. See note 3. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. + + The entries shall be applied by the VNFM according + to the rules of JSON Merge Patch (see IETF RFC + 7396). See notes 2, 3, 4, 5, 6. In case of + deleting an external CP, the list of instances to + be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extLinkPorts: + description: > + Externally provided link ports to be used to connect + external connection points to this external VL. If this + attribute is not present, the VNFM shall create the link + ports on the external VL except in the cases defined + below. See note 1. + type: array + items: + description: "This type represents an externally provided link port to be used to connect an external connection point to an external VL. * NOTE:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + extNetAttDefResourceData: + description: > + Externally provided network attachment definition + resource(s) that provide the specification of the + interface to attach external CPs to this external VL. + See note 2. It is only applicable if the external VL is + realized by a secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + This type represents a network attachment definition + resource that provides the specification of the + interface to be used to connect one or multiple + connection points to a secondary container cluster + network realizing a VL. + type: object + required: + - netAttDefResourceId + - resourceHandle + properties: + netAttDefResourceId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + extCpsDeletion: + description: > + External CPs of the VNF to be disconnected from this + external VL and to be deleted. See note 3. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. + + The entries shall be applied by the VNFM according + to the rules of JSON Merge Patch (see IETF RFC + 7396). See notes 2, 3, 4, 5, 6. In case of + deleting an external CP, the list of instances to + be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extManagedVirtualLinks: + description: > + Information about internal VLs that are managed by the NFVO. + See notes 1 and 2. + type: array + items: + description: > + This type represents an externally-managed internal VL. + + * NOTE 1: It is only applicable if the externally-managed VL + is realized by a secondary container cluster network. It + shall + not be present otherwise. + * NOTE 2: A link port is not needed for a VNFC internal + connection point connected to a secondary container cluster + network. + * NOTE 3: An example of the network attachment definition + resource when the container infrastructure service + management is a Kubernetes® instance is a network attachment definition (NAD). + + * NOTE 4: In the case that the cloud native template + included in the MCIOP describes the set of VNFC instances, + an + instance of intCp need not be included for each VNFC instance as all instances would contain the same + information. It is sufficient to include one intCp for the related CPD. The case of using, for a scalable VDU, a + cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present + document version + * NOTE 5: Both "vnfLinkPort" and "netAttDefResource" + attributes can be provided in a "ExtManagedVirtualLinkData" + to indicate + that a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs + type: object + required: + - id + - vnfVirtualLinkDescId + - resourceId + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfVirtualLinkDescId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + netAttDefResourceData: + description: > + Externally provided network attachment definition + resource(s) that provide the specification of the + interface to attach VNFC connection points to this + externallymanaged VL. See notes 1, 3 and 5. + type: array + items: + description: > + This type represents a network attachment definition + resource that provides the specification of the + interface to be used to connect one or multiple + connection points to a secondary container cluster + network realizing a VL. + type: object + required: + - netAttDefResourceId + - resourceHandle + properties: + netAttDefResourceId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + intCp: + description: > + Internal CPs of the VNF to be connected to this + externally-managed VL. See note 1 and 4. + type: array + items: + description: > + This type represents input information related to one + or more VNF internal CP instances created based on the + same CPD. + + NOTE: Cardinality greater than 1 is only applicable + for specific cases where more than one network + attachment + definition resource is needed to fulfil the connectivity requirements of the VNF internal CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall + belong to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + type: object + required: + - cpdId + - netAttDefResourceId + properties: + cpdId: + description: > + An identifier with the intention of being globally + unique. + type: string + netAttDefResourceId: + description: > + Identifiers of the “NetAttDefResourceData” + structure that provides the specification of the + interface to attach the VNF internal CP created + from the CPD identified by cpdId to a secondary + container cluster network. See note. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfLinkPort: + description: > + Externally provided link ports to be used to connect + VNFC connection points to this externally-managed VL on + this network resource. If this attribute is not present, + the VNFM shall create the link ports on the + externally-managed VL. See notes 2 and 5. + type: array + items: + description: > + This type represents an externally provided link port + to be used to connect a VNFC connection point to an + externally managed VL. + type: object + required: + - vnfLinkPortId + - resourceHandle + properties: + vnfLinkPortId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + extManagedMultisiteVirtualLinkId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimConnectionInfo: + description: > + Information about VIM or CISM connections to be used for + managing the resources for the VNF instance, or refer to + external virtual links. This attribute shall only be supported + and may be present if + - the resources for at least one of the VNFCs shall be managed by a VIM and + VNF-related resource management in direct mode is applicable. + - the resources for at least one of the VNFCs shall be managed by a CISM. + The VNFM shall apply the content of this attribute to the "vimConnectionInfo" attribute of + "VnfInstance" according to the rules of JSON Merge Patch (see + IETF RFC 7396 [5]). + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines the + structure of the "interfaceInfo" and "accessInfo" + attributes, based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values is + expected to change over time as new types or versions of + VIMs become available. The ETSI NFV registry of + VIM-related information provides access to information + about VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The structure of + the registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + selectedDeployableModule: + description: > + Identifier of a selected deployable module. + + If this attribute is present only VNFCs based on VDUs that + belong to deployable modules listed in this attribute are + requested to be instantiated or preserved if they were already + instantiated. + + If this attribute is not present the deployable modules that + were selected before the operation, and that still are defined + in the VNFD in the destination package, or the corresponding + ones according to the component mappings, remain valid. See + note 3. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + resourceCapacityDefinition: + description: > + Indicates values for resource capacity related attributes + pertaining to a descriptor. Values can only be provided for + resource capacity related attributes that have been defined + in the VNFD as being configurable. Furthermore, provided + values shall be within the allowed values indicated in the + VNFD. + type: array + items: + description: > + This type represents selected values for capacity related + VDU attributes. + + * NOTE: Resource definitions not related to a VDU are not + considered in this version of the present document. + type: object + required: + - type + properties: + tag: + description: > + Tag assigned by the issuer of a VNF LCM operation + request that contains this data type with values to be + applied to a VDU. It is used for tracking purposes. + + The tag is preserved in the run time record as long as + at least one value of the capacity related attributes + associated with that tag is still valid, i.e., it has + not been modified by a later VNF LCM operation request. + + At most one tag can be included when the data type is + used in a VNF LCM operation request. + + When the data type is used in the VnfInstance data type + it may contain multiple tags, namely those provided in + VNF LCM requests, if at least one of the values provided + in that request associated to that tag is still + applicable in the VNFCs created from this VDU, i.e., it + has not been modified by a later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: | + Type of the resource definition referenced. + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + osContainerDescData: + description: > + Indicates values for resource capacity related + attributes in an OsContainerDesc. It shall be present + when the attribute 'type' indicates OSCONTAINER and + absent otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of an OsContainer resource. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for the + container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for the + container expressed in the same units as + specified in the + requested_memory_resources_valid_values property + in VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 + [14]) for this container descriptor. See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources of the + type indicated in the key. The key is a string + that identifies an extended resource indicated in + the extended_resource_requests property in the + VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) + for this container descriptor. The value is an + integer that indicates the required amount for a + particular extended resource. See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container can + maximally use in milli-CPU. See note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required for all the + hugepages of the size indicated in the key. The + key is a string and corresponds to one of the + values of the hugepage sizes indicated in the + huge_pages_resources property in the VNFD (clause + 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this + container descriptor. The value is a number that + indicates the required total size expressed in the + same units as in the huge_pages_resource property + in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 + [14]) that indicates the valid values for required + total size for the particular hugepage size. See + note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores are + requested to be allocated to logical CPU cores + according to the cpuOperationalPowerStates + attribute. In case of "DYNAMIC", the CPU power + states of virtual CPU cores can be allocated + to logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual compute resource + of a VM. + + * NOTE: At least one of the attributes shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required for all the + hugepages of the size indicated in the key. The key + is a string and corresponds to one of the values of + the hugepage sizes indicated in the + huge_pages_requirements property in the VNFD (clause + 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for this + virtual compute descriptor. The value is a + numberthat indicates the required total size + expressed in the same units as in the + huge_pages_requirements property in the VNFD (clause + 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) that indicates + the valid vaues for required total size for the + particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores are + requested to be allocated to logical CPU cores + according to the cpuOperationalPowerStates + attribute. In case of "DYNAMIC", the CPU power + states of virtual CPU cores can be allocated to + logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size related + attribute in an VirtualStorageDesc. It shall be present + when the attribute 'type' indicates STORAGE and absent + otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual storage + resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + certificateConfigurationData: + description: > + This type provides input information related to certificate + management. + + ETSI GS NFV-SOL 009 [i.18] specifies the means to discover the + applicable certificate management mode of VNFM and configure + into the NFVO applicable certificate management mode via the + "NFV-MANO Configuration and Information Management" interface + type: object + properties: + overridingCertificateProfiles: + description: > + Overriding certificate profile. This overrides the + certificateBaseProfile provided in the VNFD, and the CA + and CMF can additionally override aspects of this + certificateBaseProfile at later point in the VNF lifecycle + if necessary to meet operator security policy. + type: array + items: + description: > + NOTE: At least one overriding attributes shall be + present, otherwise shall be absent. + + This type provides input information to override + certificate base profile for certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + issuer: + description: Issuer of certificates. See note. + type: string + issuerUniqueIdentifier: + description: > + An identifier with the intention of being globally + unique. + type: string + subject: + description: > + This type provides input information related to the + subject of the certificate. + + NOTE: At least one overriding attributes shall be + present, otherwise shall be absent. + type: object + properties: + commonName: + description: > + Information of the certification target subject + FQDN. Can be set empty when this certificate is + used for encrypted communication using IP + address. See note. + type: string + organization: + description: >- + Information of the certification target subject + Organization. See note. + type: string + country: + description: >- + Information of the certification target subject + Country. See note. + type: string + state: + description: >- + Information of the certification target subject + State. See note. + type: string + locality: + description: >- + Information of the certification target subject + Locality. See note. + type: string + emailAddress: + description: >- + Information of the certification contact email + address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of being globally + unique. + type: string + basicConstraints: + description: Basic constraints of certificates. See note. + type: string + issuerAltName: + description: >- + Alternative name of issuer of certificates in this + NS. See note. + type: array + items: + type: string + subjectAltName: + description: > + Alternative name of subject of certificates. Shall + be present when this certificate is used for + encrypted communication using IP address and + subjectAltName attribute of CertificateBaseProfile + in CertificateDesc of VNFD is empty (see ETSI GS + NFV-IFA 011 [14], clause 7.1.19.4). See note. + type: array + items: + type: string + nameConstraints: + description: Name constraints of certificates. See note. + type: array + items: + type: string + securityPolicy: + description: | + Security policy to be satisfied for the certificate. + type: array + items: + description: > + This type provides input information related to security + policy for certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + maxValidityPeriod: + description: Allowed max validity period for certificates. + type: number + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: number + cmfData: + description: > + This type provides input information related to CMF for + certificate management. + type: object + required: + - endPoint + - supportedProtocols + properties: + endPoint: + description: End point of CMF instance. + type: object + properties: + 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 + link: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + supportedProtocols: + description: Supported protocols by CMF instance. + type: array + items: + description: Supported protocol by CMF instance. + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + upgradeType: + description: > + Indicates upgrade type when change the current VNF Package on + which a VNF instance is based. Permitted values: + * ROLLING_UPGRADE + * BLUE_GREEN + See note 4. + type: string + enum: + - ROLLING_UPGRADE + - BLUE_GREEN + required: true + LccnSubscriptionRequest: + description: | + Details of the subscription to be created. + content: + application/json: + schema: + description: > + This type represents a subscription request related to + notifications about VNF lifecycle changes. + type: object + required: + - callbackUri + properties: + filter: + description: "This type represents a subscription filter related to notifications about VNF lifecycle changes.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of \n the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdId + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId values + listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, from + one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tVnfLcmOperationOccurrenceNotification -\tVnfIdentifierCreationNotification -\tVnfIdentifierDeletionNotification See note.\n" + type: array + items: + type: string + enum: + - VnfLcmOperationOccurrenceNotification + - VnfIdentifierCreationNotification + - VnfIdentifierDeletionNotification + operationTypes: + description: > + Match particular VNF lifecycle operation types for the + notification of type + VnfLcmOperationOccurrenceNotification. May be present if + the "notificationTypes" attribute contains the value + "VnfLcmOperationOccurrenceNotification", and shall be + absent otherwise. + type: array + items: + description: > + The enumeration LcmOpType defines the permitted values + to represent VNF lifecycle operation types in VNF + lifecycle management operation occurrence resources and + VNF lifecycle management operation occurrence + notifications. + + Value | Description ------|------------ INSTANTIATE | + Represents the "Instantiate VNF" LCM operation. SCALE + | Represents the "Scale VNF" LCM operation. + SCALE_TO_LEVEL | Represents the "Scale VNF to Level" LCM + operation. CHANGE_FLAVOUR | Represents the "Change VNF + Flavour" LCM operation. TERMINATE | Represents the + "Terminate VNF" LCM operation. HEAL | Represents the + "Heal VNF" LCM operation. OPERATE | Represents the + "Operate VNF" LCM operation. CHANGE_EXT_CONN | + Represents the "Change external VNF connectivity" LCM + operation. MODIFY_INFO | Represents the "Modify VNF + Information" LCM operation. CREATE_SNAPSHOT | Represents + the "Create VNF Snapshot" LCM operation. + REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF + Snapshot" LCM operation. CHANGE_VNFPKG | Represents the + "Change current VNF package" LCM operation. + SELECT_DEPL_MODS | Represents the “Select VNF deployable + modules” LCM operation + type: string + enum: + - INSTANTIATE + - SCALE + - SCALE_TO_LEVEL + - CHANGE_FLAVOUR + - TERMINATE + - HEAL + - OPERATE + - CHANGE_EXT_CONN + - MODIFY_INFO + - CREATE_SNAPSHOT + - REVERT_TO_SNAPSHOT + - CHANGE_VNFPKG + - SELECT_DEPL_MODS + operationStates: + description: > + Match particular LCM operation state values as reported in + notifications of type + VnfLcmOperationOccurrenceNotification. May be present if + the "notificationTypes" attribute contains the value + "VnfLcmOperationOccurrenceNotification", and shall be + absent otherwise. + type: array + items: + description: > + STARTING: The LCM operation is starting. PROCESSING: The + LCM operation is currently in execution. COMPLETED: The + LCM operation has been completed successfully. + FAILED_TEMP: The LCM operation has failed and execution + has stopped, but the execution of the operation is not + considered to be closed. FAILED: The LCM operation has + failed and it cannot be retried or rolled back, as it is + determined that such action won't succeed. ROLLING_BACK: + The LCM operation is currently being rolled back. + ROLLED_BACK: The LCM operation has been successfully + rolled back, i.e. The state of the VNF prior to the + original operation invocation has been restored as + closely as possible. + type: string + enum: + - STARTING + - PROCESSING + - COMPLETED + - FAILED_TEMP + - FAILED + - ROLLING_BACK + - ROLLED_BACK + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + authentication: + description: > + * NOTE 1 : The clientId and clientPassword passed in a + subscription shall not be the same as the clientId and + clientPassword that are used to obtain authorization for API requests. Client credentials may differ between + subscriptions. The value of clientPassword should be generated by a random process. + * NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT + which uses mutual authentication based on X.509 + certificates, this mode which uses client password to authenticate may be used in the access token request + toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations + (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details. + * NOTE 3: The following values that were included up to + version 3.4.1 of the present document have been removed: + "BASIC" (to signal the use of the basic HTTP authentication) has been removed because it is insecure. + "TLS_CERT" to signal an alternative non-token based authorization method using TLS certificates has been + removed because the method is no longer supported. + * NOTE 4: The client certificate is established by means + outside the scope of the present document. + type: object + required: + - authType + properties: + authType: + description: > + Defines the types of Authentication / Authorization which + the API consumer is willing to accept when receiving a + notification. Permitted values (see note 3): * + OAUTH2_CLIENT_CREDENTIALS: In every + HTTP request to the notification endpoint, use + an OAuth 2.0 token, obtained using the client + credentials grant type after authenticating + using client identifier and client password + towards the token endpoint. + * OAUTH2_CLIENT_CERT: In every HTTP + request to the notification endpoint, use an + OAuth 2.0 token, obtained using the client + credentials grant type after mutually + authenticating using client identifier and X.509 + certificates towards the token endpoint. + type: array + items: + type: string + enum: + - OAUTH2_CLIENT_CREDENTIALS + - OAUTH2_CLIENT_CERT + paramsOauth2ClientCert: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CERT. + + Shall be present if authType is "OAUTH2_CLIENT_CERT" and + the contained information has not been provisioned out of + band. + + Shall be absent otherwise. + type: object + required: + - clientId + - certificateRef + - tokenEndpoint + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. + type: string + certificateRef: + description: > + Fingerprint of the client certificate. The hash + function shall use SHA256 or higher. See note 4. + type: string + required: + - type + - value + properties: + type: + description: | + A string defined in IETF RFC 8259. + type: string + value: + description: | + A string defined in IETF RFC 8259. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + paramsOauth2ClientCredentials: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CREDENTIALS. + + Shall be present if authType is + "OAUTH2_CLIENT_CREDENTIALS" and the contained information + has not been provisioned out of band. + + Shall be absent otherwise. + + See note 2. + type: object + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. Shall be present if it has not been + provisioned out of band. See note 1. + type: string + clientPassword: + description: > + Client password to be used in the access token request + of the OAuth 2.0 client credentials grant type. Shall + be present if it has not been provisioned out of band. + See note 1. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + verbosity: + description: > + The enumeration LcmOpOccNotificationVerbosityType provides + values to control the verbosity of LCM operation occurrence + notifications. * FULL: This signals a full notification which + contains all change details. * SHORT: This signals a short + notification which omits large-volume change details to reduce + the size of data to + be sent via the notification mechanism. + type: string + enum: + - FULL + - SHORT + required: true + CreateVnfSnapshotRequest: + description: > + Parameters for the "Create VNF Snapshot" operation, as defined in clause + 5.5.2.21. + content: + application/json: + schema: + description: > + This type represents request parameters for the "Create VNF + Snapshot" LCM operation which takes a snapshot of a VNF instance + and populates a previously-created "Individual VNF snapshot" + resource with the content of the snapshot. + type: object + required: + - vnfSnapshotResId + properties: + vnfSnapshotInfoId: + description: | + An identifier with the intention of being globally unique. + type: string + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + userDefinedData: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + required: true + RevertToVnfSnapshotRequest: + description: > + Parameters for the Revert to VNF snapshot operation, as defined in + clause 5.5.2.26. + content: + application/json: + schema: + description: > + This type represents request parameters for the "Revert to VNF + Snapshot" operation. + type: object + required: + - vnfSnapshotInfoId + properties: + vnfSnapshotInfoId: + description: | + An identifier with the intention of being globally unique. + type: string + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + required: true + SelectVnfDeployableModulesRequest: + description: > + This type represents request parameters for the "Select VNF deployable + modules" operation. + content: + application/json: + schema: + description: > + This type represents request parameters for the "Select VNF + deployable modules" operation. + + * NOTE 1: Thus, the select VNF deployable modules operation cannot + be used as a scale VNF operation + to scale VNFCs that were already instantiated. + * NOTE 2: Thus, the select VNF deployable modules operation cannot + be used as a scale + VNF operation to vertically scale VNFCs that were already instantiated. + type: object + properties: + selectedDeployableModule: + description: > + Identifier of a selected deployable module, as defined in the + VNFD. VNFCs based on VDUs that belong to deployable modules + listed in this attribute will be instantiated if not already + instantiated. VNFCs based on VDUs that belong to deployable + modules not listed in this attribute and that were already + instantiated will be terminated. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + targetScaleLevelInfo: + description: > + Defines the target scale levels of scaling aspects of the VDUs + that belong to selected deployable modules. If this attribute + is not present or if there are VDUs that belong to selected + deployable modules that take no part in any of the scaling + aspects indicated in this attribute, the VNFCs based on those + VDUs shall be instantiated according to the currently valid + VNF scale level or instantiation level. This attribute should + only contain scale level information of scaling aspects + associated with VDUs that will be used to instantiate VNFCs as + a result of this operation. If it contains other scale level + information, it shall be ignored. See note. + type: array + items: + description: > + This type represents the scale level of a VNF instance + related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceCapacityDefinition: + description: > + Indicates values for resource capacity related attributes + pertaining to a descriptor. Values can only be provided for + resource capacity related attributes that have been defined in + the VNFD as being configurable. Furthermore, provided values + shall be within the allowed values indicated in the VNFD. + + This attribute should only contain information about resource + capacity related attributes of VDUs that will be used to + instantiate VNFCs as a result of this operation. If it + contains information about attributes of other VDUs it shall + be ignored. See note 2. + type: array + items: + description: > + This type represents selected values for capacity related + VDU attributes. + + * NOTE: Resource definitions not related to a VDU are not + considered in this version of the present document. + type: object + required: + - type + properties: + tag: + description: > + Tag assigned by the issuer of a VNF LCM operation + request that contains this data type with values to be + applied to a VDU. It is used for tracking purposes. + + The tag is preserved in the run time record as long as + at least one value of the capacity related attributes + associated with that tag is still valid, i.e., it has + not been modified by a later VNF LCM operation request. + + At most one tag can be included when the data type is + used in a VNF LCM operation request. + + When the data type is used in the VnfInstance data type + it may contain multiple tags, namely those provided in + VNF LCM requests, if at least one of the values provided + in that request associated to that tag is still + applicable in the VNFCs created from this VDU, i.e., it + has not been modified by a later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: | + Type of the resource definition referenced. + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + osContainerDescData: + description: > + Indicates values for resource capacity related + attributes in an OsContainerDesc. It shall be present + when the attribute 'type' indicates OSCONTAINER and + absent otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of an OsContainer resource. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for the + container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for the + container expressed in the same units as + specified in the + requested_memory_resources_valid_values property + in VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 + [14]) for this container descriptor. See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources of the + type indicated in the key. The key is a string + that identifies an extended resource indicated in + the extended_resource_requests property in the + VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) + for this container descriptor. The value is an + integer that indicates the required amount for a + particular extended resource. See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container can + maximally use in milli-CPU. See note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required for all the + hugepages of the size indicated in the key. The + key is a string and corresponds to one of the + values of the hugepage sizes indicated in the + huge_pages_resources property in the VNFD (clause + 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this + container descriptor. The value is a number that + indicates the required total size expressed in the + same units as in the huge_pages_resource property + in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 + [14]) that indicates the valid values for required + total size for the particular hugepage size. See + note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores are + requested to be allocated to logical CPU cores + according to the cpuOperationalPowerStates + attribute. In case of "DYNAMIC", the CPU power + states of virtual CPU cores can be allocated + to logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual compute resource + of a VM. + + * NOTE: At least one of the attributes shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required for all the + hugepages of the size indicated in the key. The key + is a string and corresponds to one of the values of + the hugepage sizes indicated in the + huge_pages_requirements property in the VNFD (clause + 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for this + virtual compute descriptor. The value is a + numberthat indicates the required total size + expressed in the same units as in the + huge_pages_requirements property in the VNFD (clause + 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) that indicates + the valid vaues for required total size for the + particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores are + requested to be allocated to logical CPU cores + according to the cpuOperationalPowerStates + attribute. In case of "DYNAMIC", the CPU power + states of virtual CPU cores can be allocated to + logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size related + attribute in an VirtualStorageDesc. It shall be present + when the attribute 'type' indicates STORAGE and absent + otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual storage + resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + required: true + CreateVnfSnapshotInfoRequest: + description: > + The VNF snapshot resource creation parameters, as defined in clause + 5.5.2.20. + content: + application/json: + schema: + description: "This type represents request parameters for the creation of an \"Individual VNF snapshot\" \nresource which can be populated with content obtained by invoking the \"Create VNF snapshot\" \nLCM operation or extracted from a VNF snapshot package.\n\nNOTE:\tThe present attribute shall be provided if the \"Individual VNF snapshot\" resource is \n requested to be created as part of a VNF snapshot package extraction.\n" + type: object + properties: + vnfSnapshotPkgId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfSnapshot: + description: | + This type represents a VNF snapshot. + type: object + required: + - id + - vnfInstanceId + - triggeredAt + - vnfdId + - vnfInfo + - vnfcSnapshots + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + creationStartedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + creationFinishedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfInstance: + description: "This type represents a VNF instance.\nNOTE:\tClause B.3.2 provides examples illustrating the relationship among the different run-time \n information elements (CP, VL and link ports) used to represent the connectivity of a VNF.\n\nNOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist between \n the previous and the newly referred VNF package, i.e. when the new VNFD is changed with \n respect to the previous VNFD in other aspects than merely referencing to other VNF software \n images. In order to avoid misalignment of the VnfInstance with the current VNF's on-boarded \n VNF Package, the values of attributes in the VnfInstance that have corresponding attributes \n in the VNFD shall be kept in sync with the values in the VNFD.\nNOTE 2:\tETSI GS NFV-SOL 001 [14] specifies the structure and format of the VNFD based on TOSCA specifications. NOTE 3:\tVNF configurable properties are sometimes also referred to as configuration parameters applicable \n to a VNF. Some of these are set prior to instantiation and cannot be modified if the VNF is instantiated, \n some are set prior to instantiation (are part of initial configuration) and can be modified later, \n and others can be set only after instantiation. The applicability of certain configuration may \n depend on the VNF and the required operation of the VNF at a certain point in time.\nNOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes \n of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared in the VNFD with a defined \n initial value. The defined initial values can be declared in the VNFD, and/or, in case of \"metadata\", \n obtained from the \"CreateVnfRequest\" structure. Child attributes of \"vnfConfigurableProperties\", \n \"metadata\" and \"extensions\" that have no defined initial value shall not be created, in order to be \n consistent with the semantics of the JSON Merge Patch method (see IETF RFC 7396) that interprets null \n values as deletion request.\nNOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a \n multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same \n VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed \n multi-site VL instance (refer to clause 5.5.3.3).\nNOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity, they shall \n not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\nNOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing \n the trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\nNOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the \n VNF LCM operation explicitly indicates the scale level for the aspect.\nNOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n" + type: object + required: + - id + - vnfdId + - vnfProvider + - vnfProductName + - vnfSoftwareVersion + - vnfdVersion + - instantiationState + - _links + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceName: + description: > + Name of the VNF instance. This attribute can be + modified with the PATCH method. + type: string + vnfInstanceDescription: + description: > + Human-readable description of the VNF instance. This + attribute can be modified with the PATCH method. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProvider: + description: > + Provider of the VNF and the VNFD. The value is copied + from the VNFD. + type: string + vnfProductName: + description: > + Name to identify the VNF Product. The value is copied + from the VNFD. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + vimConnectionInfo: + description: > + Information about VIM or CISM connections to be used + for managing the resources for the VNF instance. The + keys of the map, each of which identifies information + about a particular VIM connection, are managed by the + NFVO and referenced from other data structures via the + "vimConnectionId" attribute. This attribute shall only + be supported and present if - the resources of at + least of the VNFCs are managed by a VIM and + VNF-related resource management in direct mode is + applicable. - the resources of at least of the VNFCs + are managed by a CISM. This attribute can be modified + with the PATCH method. If VIM connection information + is provisioned to the VNFM by means outside the scope + of the present document, the information in the + "vimConnectionInfo" attribute provides necessary + information for binding the VnfInstance representing + the "Individual VNF instance" to the applicable VIM + connection information used to perform resource + management for the VNF instance. See also the + definition of the "VimConnectionInfo" in clause + 4.4.1.6. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being + globally unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute + determines the structure of the "interfaceInfo" + and "accessInfo" attributes, based on the type + of the VIM., CISM, CIR or MCIOP repository. The + set of permitted values is expected to change + over time as new types or versions of VIMs + become available. The ETSI NFV registry of + VIM-related information provides access to + information about VimConnectionInfo definitions + for various VIM, CISM, CIR or MCIOP repository + types. The structure of the registry is defined + in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + cirConnectionInfo: + description: > + Information about the CIR connection for managing OS + container images for the VNF instance. Shall be + present when all or part of the VNF is realized by a + set of OS containers and shall be absent otherwise. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being + globally unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute + determines the structure of the "interfaceInfo" + and "accessInfo" attributes, based on the type + of the VIM., CISM, CIR or MCIOP repository. The + set of permitted values is expected to change + over time as new types or versions of VIMs + become available. The ETSI NFV registry of + VIM-related information provides access to + information about VimConnectionInfo definitions + for various VIM, CISM, CIR or MCIOP repository + types. The structure of the registry is defined + in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + mciopRepositoryInfo: + description: > + Information about the MCIOP repository for the VNF + instance. Shall be present when all or part of the VNF + is realized by a set of OS containers and shall be + absent otherwise. See note 1. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being + globally unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute + determines the structure of the "interfaceInfo" + and "accessInfo" attributes, based on the type + of the VIM., CISM, CIR or MCIOP repository. The + set of permitted values is expected to change + over time as new types or versions of VIMs + become available. The ETSI NFV registry of + VIM-related information provides access to + information about VimConnectionInfo definitions + for various VIM, CISM, CIR or MCIOP repository + types. The structure of the registry is defined + in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + certificateInfo: + description: > + This type provides input information related to + certificate and certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + certificateConfigurationInfo: + description: > + This type provides input information related to + certificate management. + type: object + required: + - securityPolicy + properties: + certificateBaseProfile: + description: Information for certificate profile. + type: array + items: + description: > + NOTE: At least one overriding attributes + shall be present, otherwise shall be absent. + + This type provides input information to + override certificate base profile for + certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + issuer: + description: Issuer of certificates. See note. + type: string + issuerUniqueIdentifier: + description: > + An identifier with the intention of + being globally unique. + type: string + subject: + description: > + This type provides input information + related to the subject of the + certificate. + + NOTE: At least one overriding attributes + shall be present, otherwise shall be + absent. + type: object + properties: + commonName: + description: > + Information of the certification target + subject FQDN. Can be set empty when this + certificate is used for encrypted + communication using IP address. See + note. + type: string + organization: + description: >- + Information of the certification target + subject Organization. See note. + type: string + country: + description: >- + Information of the certification target + subject Country. See note. + type: string + state: + description: >- + Information of the certification target + subject State. See note. + type: string + locality: + description: >- + Information of the certification target + subject Locality. See note. + type: string + emailAddress: + description: >- + Information of the certification contact + email address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of + being globally unique. + type: string + basicConstraints: + description: >- + Basic constraints of certificates. See + note. + type: string + issuerAltName: + description: >- + Alternative name of issuer of + certificates in this NS. See note. + type: array + items: + type: string + subjectAltName: + description: > + Alternative name of subject of + certificates. Shall be present when this + certificate is used for encrypted + communication using IP address and + subjectAltName attribute of + CertificateBaseProfile in + CertificateDesc of VNFD is empty (see + ETSI GS NFV-IFA 011 [14], clause + 7.1.19.4). See note. + type: array + items: + type: string + nameConstraints: + description: >- + Name constraints of certificates. See + note. + type: array + items: + type: string + securityPolicy: + description: >- + Information for security policy to be + satisfied for certificate. + type: array + items: + description: > + This type provides input information related + to security policy for certificate + management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + maxValidityPeriod: + description: >- + Allowed max validity period for + certificates. + type: number + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: number + delegationSupportedCertificateManagements: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + cmfInfo: + description: > + This type provides input information related + to CMF for certificate management. + type: object + required: + - id + - endPoint + - supportedProtocol + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + endPoint: + description: End point of CMF instance. + type: object + properties: + 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 + link: + description: > + This type represents a link to a + resource using an absolute URI. + type: object + required: + - href + properties: + href: + description: > + String formatted according to IETF RFC + 3986. + type: string + supportedProtocol: + description: Supported protocols by CMF instance. + type: array + items: + description: Supported protocol by CMF instance. + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + certificateChain: + description: Certificate chain that this CMF provides. + type: array + items: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + certificateContents: + description: > + Information for contents of issued certificates. + The information contained in this attribute may be + updated over time during the VNF LCM, e.g., + certificate(s) renewal. + type: array + items: + description: > + This type provides input information related to + certificate content. + + NOTE: The CertificateDesc data type is defined + in clause 7.1.19.2 of ETSI GS NFV IFA 011 [10]. + type: object + required: + - id + - certificateDescId + - certificateType + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + certificateDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + certificateType: + description: Type of this certificate. + type: string + enum: + - VNFCI_CERT + - VNFOAM_CERT + supportedCertificateManagements: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + version: + description: | + A version. + type: string + serialNumber: + description: Serial number of this certificate. + type: integer + signatureAlgorithm: + description: Algorithm of this certificate's signature. + type: string + issuer: + description: Issuer of this certificate. + type: string + notBefore: + description: > + Date-time stamp. Representation: String + formatted according to IETF RFC 3339. + type: string + format: date-time + notAfter: + description: > + Date-time stamp. Representation: String + formatted according to IETF RFC 3339. + type: string + format: date-time + subject: + description: Subject of this certificate. + type: string + publicKeyAlgorithm: + description: Algorithm of this certificate's public key. + type: string + publicKey: + description: Public key of this certificate. + type: string + certificateExtensions: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + instantiationState: + description: > + The instantiation state of the VNF. Permitted values: + - NOT_INSTANTIATED: The VNF instance is terminated or + not instantiated. - INSTANTIATED: The VNF instance is + instantiated. + type: string + enum: + - NOT_INSTANTIATED + - INSTANTIATED + instantiatedVnfInfo: + description: > + Information specific to an instantiated VNF instance. + This attribute shall be present if the + instantiateState attribute value is INSTANTIATED. + type: object + required: + - flavourId + - vnfState + properties: + flavourId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfState: + description: > + STARTED: The VNF instance is up and running. + STOPPED: The VNF instance has been shut down. + type: string + enum: + - STARTED + - STOPPED + vnfPowerState: + description: > + This type represents information about the power + state of a VNF instance. + type: object + required: + - powerProfileId + - name + properties: + powerProfileId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + name: + description: > + Name of the power profile as provided in the + VNFD. + type: string + powerConsumptionInfo: + description: > + This type represents information about + estimated power consumption of the resources + associated with the power profile, as provided + in the VNFD. + type: object + required: + - minPowerConsumption + - maxPowerConsumption + - averagePowerConsumption + properties: + minPowerConsumption: + description: > + Minimum power consumption of this power + profile. Unit is KW/h. + type: integer + maxPowerConsumption: + description: > + Maximum power consumption of this power + profile. Unit is KW/h. + type: integer + averagePowerConsumption: + description: > + Average power consumption of this power + profile. Unit is KW/h. + type: integer + scaleStatus: + description: > + Scale status of the VNF, one entry per aspect. + Represents for every scaling aspect how "big" the + VNF has been scaled w.r.t. that aspect. + + This attribute shall be present if the VNF + supports scaling. See clause B.2 for an + explanation of VNF scaling. + + For an aspect that has not been deployed because + the related deployableModule has not been + selected, it indicates the scale level that has + been requested in the instantiation or in a + scaling operation, or, if none has been requested + in any of them, the scale level applicable to the + aspect based on the default instantiation level. + See note 8. + type: array + items: + description: > + This type represents the scale level of a VNF + instance related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being + globally unique. + type: string + maxScaleLevels: + description: > + Maximum allowed scale levels of the VNF, one entry + per aspect. This attribute shall be present if the + VNF supports scaling. + type: array + items: + description: > + This type represents the scale level of a VNF + instance related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being + globally unique. + type: string + selectedDeployableModule: + description: > + References a currently selected deployable module, + as defined in the VNFD, that has already + completed the instantiation of its VNFCs. + type: array + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + resourceCapacityDefinition: + description: > + Shows current values of VDU attributes related to + resource capacity, if different to the default + values from the VNFD, as indicated in the (one or + more) request(s) of all completed VNF LCM + operation(s) that contain this attribute. If an + attribute value has been modified multiple times, + only the last value is shown. The values indicated + in this attribute are applicable to all VNFC + instances based on the VDU to which the + resourceCapacityDefinition is related. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes. + + * NOTE: Resource definitions not related to a + VDU are not considered in this version of the + present document. + type: object + required: + - type + properties: + tag: + description: > + Tag assigned by the issuer of a VNF LCM + operation request that contains this data + type with values to be applied to a VDU. It + is used for tracking purposes. + + The tag is preserved in the run time record + as long as at least one value of the + capacity related attributes associated with + that tag is still valid, i.e., it has not + been modified by a later VNF LCM operation + request. + + At most one tag can be included when the + data type is used in a VNF LCM operation + request. + + When the data type is used in the + VnfInstance data type it may contain + multiple tags, namely those provided in VNF + LCM requests, if at least one of the values + provided in that request associated to that + tag is still applicable in the VNFCs created + from this VDU, i.e., it has not been + modified by a later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: | + Type of the resource definition referenced. + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + osContainerDescData: + description: > + Indicates values for resource capacity + related attributes in an OsContainerDesc. + It shall be present when the attribute + 'type' indicates OSCONTAINER and absent + otherwise. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes of an + OsContainer resource. + + * NOTE: At least one of the attributes + shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for + the container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for + the container expressed in the same + units as specified in the + requested_memory_resources_valid_values + property in VNFD (clause 6.8.12 in ETSI + GS NFV-SOL 001 [14]) for this container + descriptor. See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources + of the type indicated in the key. The + key is a string that identifies an + extended resource indicated in the + extended_resource_requests property in + the VNFD (clause 6.8.12 in ETSI GS + NFV-SOL 001 [14]) for this container + descriptor. The value is an integer that + indicates the required amount for a + particular extended resource. See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container + can maximally use in milli-CPU. See + note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required + for all the hugepages of the size + indicated in the key. The key is a + string and corresponds to one of the + values of the hugepage sizes indicated + in the huge_pages_resources property in + the VNFD (clause 6.8.12 in ETSI GS + NFV-SOL 001 [14]) for this container + descriptor. The value is a number that + indicates the required total size + expressed in the same units as in the + huge_pages_resource property in the VNFD + (clause 6.8.12 in ETSI GS NFV-SOL 001 + [14]) that indicates the valid values + for required total size for the + particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power + state configuration data for the virtual + compute or OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU + cores are requested to be allocated to + logical CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states + of virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on + core utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for + capacity related VDU attributes of the + virtual compute resource of a VM. + + * NOTE: At least one of the attributes shall + be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required + for all the hugepages of the size + indicated in the key. The key is a + string and corresponds to one of the + values of the hugepage sizes indicated + in the huge_pages_requirements property + in the VNFD (clause 6.2.7.2 in ETSI GS + NFV-SOL 001 [14]) for this virtual + compute descriptor. The value is a + numberthat indicates the required total + size expressed in the same units as in + the huge_pages_requirements property in + the VNFD (clause 6.2.7.2 in ETSI GS + NFV-SOL 001 [14]) that indicates the + valid vaues for required total size for + the particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power + state configuration data for the virtual + compute or OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU + cores are requested to be allocated to + logical CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states + of virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on + core utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size + related attribute in an VirtualStorageDesc. + It shall be present when the attribute + 'type' indicates STORAGE and absent + otherwise. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes of the + virtual storage resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + extCpInfo: + description: > + Information about the external CPs exposed by the + VNF instance. When trunking is enabled, the list + of entries includes both, external CPs + corresponding to parent ports of a trunk, and + external CPs associated to sub-ports of a + trunk.See note 7. + type: array + items: + description: "This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n" + type: object + required: + - id + - cpdId + - cpConfigId + - cpProtocolInfo + oneOf: + - required: + - associatedVnfcCpId + - required: + - associatedVipCpId + - required: + - associatedVnfVirtualLinkId + properties: + id: + 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 + cpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolInfo: + description: | + Network protocol information for this CP. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + extLinkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + associatedVnfcCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVipCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVirtualCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVnfVirtualLinkId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceInfo” + structure that provides the specification of + the interface to attach the connection point + to a secondary container cluster network. + See notes 3 and 4. + + It shall be present if the external CP is + associated to a VNFC realized by one or a + set of OS containers and is connected to a + secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this VNF CP + instance uses. Shall be present when using + in delegation-mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + cpSecurityGroupInfo: + description: > + This type provides the list of active + security group rules applied to an external + CP instance. The type identifies which + "SecurityGroupRule" specified in the VNFD + are activated and the values of its + attributes. + type: object + required: + - securityGroupRuleId + - etherType + - protocol + - portRangeMin + - portRangeMax + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + description: + description: > + Human readable description of the + security group rule. + type: string + etherType: + description: > + Indicates the protocol carried over the + Ethernet layer. Permitted values: IPV4, + IPV6. + type: string + enum: + - IPV4 + - IPV6 + protocol: + description: > + Indicates the protocol carried over the + IP layer. Permitted values: any protocol + defined in the IANA protocol registry + (refer to clause 9.10.1.2 ofd ETSI GS + NFV-SOL 001 for further information). + type: string + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. + type: integer + vipCpInfo: + description: > + VIP CPs that are part of the VNF instance. Shall + be present when that particular VIP CP of the VNFC + instance is associated to an external CP of the + VNF instance. May be present otherwise. + type: array + minItems: 1 + items: + description: "This type provides information related to virtual IP (VIP) CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n" + type: object + required: + - cpInstanceId + - cpdId + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There + shall be one cpProtocolInfo for layer 3. + There may be one cpProtocolInfo for layer 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + associatedVnfcCpIds: + description: > + Identifiers of the VnfcCps that share the + virtual IP address allocated to the VIP CP + instance. See note. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + virtualCpInfo: + description: > + Virtual CPs that are part of the VNF instance. + Shall be present when a particular Virtual CP is + associated to an external CP of the VNF instance. + May be present otherwise. + type: array + items: + description: > + This type provides information related to a + virtual CP instance of a VNF. + + NOTE 1: A consumer of the VNF LCM interface can + learn the actual VNFC instances implementing the + service + accessible via the virtual CP instance by querying the "vnfcResourceInfo" from the "InstantiatedVnfInfo" + and filtering by corresponding "vduIds" values. + NOTE 2: The information can be omitted because + it is already available as part of the external + CP information in the + VnfExtCpInfo structure. + type: object + required: + - cpInstanceId + - cpdId + - resourceHandle + - vduIds + properties: + cpInstanceId: + 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 + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There + shall be one cpProtocolInfo for each layer + protocol supported. This attribute may be + omitted if the virtual CP is exposed as an + external CP. See note 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vduIds: + description: > + Reference to the VDU(s) which implement the + service accessible via the virtual CP + instance. See note 1. + type: array + minItems: 1 + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + additionalServiceInfo: + description: > + Additional service identification + information of the virtual CP instance. + type: array + items: + description: > + This type provides additional service + information of the virtual CP instance + used to expose properties of the virtual + CP to NFV-MANO. + + NOTE: This attribute shall only be present + if additional information is needed to + identify the service + termination within the VNF, such as for example a URL path information in an HTTP request required + to allow a single virtual CP IP address to be used for several HTTP based services that use the + same port number. + type: object + required: + - portInfo + properties: + portInfo: + description: > + Service port numbers exposed by the + virtual CP instance. + minItems: 1 + type: array + items: + description: > + This type describes the service + identifying port properties exposed by + the virtual CP instance. + type: object + required: + - name + - port + - portConfigurable + properties: + name: + description: > + The name of the port exposed by the + virtual CP instance. + type: string + protocol: + description: > + The L4 protocol for this port exposed by + the virtual CP instance. + + Permitted values: - TCP - UDP - SCTP + type: string + enum: + - TCP + - UDP + - SCTP + port: + description: > + The L4 port number exposed by the + virtual CP instance. + type: integer + portConfigurable: + description: > + The Boolean is a data type having two + values (true and false). + type: boolean + serviceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + extVirtualLinkInfo: + description: > + Information about the external VLs the VNF + instance is connected to. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the current + CP configuration information for the + connection of external CPs to the external + virtual link. See note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be + configured on the CP instances created + from the respective CPD. + + The key of the map which identifies the + individual VnfExtCpConfig entries is of + type "IdentifierInVnf" and is managed by + the NFVO. + + The entries shall be applied by the VNFM + according to the rules of JSON Merge + Patch (see IETF RFC 7396). See notes 2, + 3, 4, 5, 6. In case of deleting an + external CP, the list of instances to be + deleted. + type: object + additionalProperties: + description: > + This type represents an externally + provided link port, or a network + attachment definition resource of + secondary container cluster network, or + network address information per instance + of an external connection point. In the + case of VM-based deployment of the VNFC + exposing the external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based + deployment of the VNFC exposing the + external CP, the VNFM shall use the + network attachment definition resource + of secondary container cluster network + when connecting the CP to the external + VL. + + * NOTE 1: The following conditions apply + to the attributes "linkPortId" and + "cpProtocolData" for an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply + to the attributes “netAttDefResourceId” + and “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is + only applicable for specific cases where + more than one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but + not both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of + being globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create + a dedicated link port for the external + CP. If set to True, the VNFM shall + create a link port. If set to False, the + VNFM shall not create a link port. This + attribute is only applicable for + external CP instances without a floating + IP address that expose a VIP CP instance + for which a dedicated IP address is + allocated. It shall be present in that + case and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceData” structure that + provides the specification of the + interface to attach the external CP to a + secondary container cluster network. It + is only applicable if the external CP is + connected or to be connected to a + secondary container cluster network. It + shall not be present if the external CP + is related to a virtual network not + categorized as secondary container + cluster network. See notes 2, 3 and 4. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects + the CP to a VL and the domain names for + the external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security + groups. The parameters identify which + "SecurityGroupRule" specified in the + VNFD is activated/deactivated and for an + activated security group rule the values + of attributes defined in the VNFD that + can be overriden such as "portRangeMin" + and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extNetAttDefResource: + description: > + Network attachment definition resources that + provide the specification of the interface + to attach connection points to this VL. + type: array + items: + description: > + This type contains information related to + a network attachment definition resource + that provides the specification of the + interface used to connect one or multiple + connection points to a secondary + container cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of + being globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated + to this network attachment definition + resource. Shall be present when the + network attachment definition resource + is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to + this network attachment definition + resource. May be present when the + network attachment definition resource + is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and + been associated to the CP. + type: array + items: + type: string + extManagedVirtualLinkInfo: + description: > + Information about the externally-managed internal + VLs of the VNF instance. See notes 5 and 6. + type: array + items: + description: > + This type provides information about an + externally-managed virtual link. Note: Both + "vnfLinkPort" and "vnfNetAttDefResource" + attributes can be present in an + "ExtManagedVirtualLinkInfo" to + indicate that a single internal virtual link is providing connectivity for both VM-based and container-based + VNFCs. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + vnfLinkPorts: + description: | + Link ports of this VL. See note. + type: array + items: + description: > + This type represents a link port of an + internal VL of a VNF. + + NOTE 1: Either cpInstanceId with + cpInstanceType set to "EXT_CP" or any + combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 + provides examples for configurations where + both vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is + scoped by the value of "vimConnectionId" + in the "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vnfNetAttDefResource: + description: > + Network attachment definition resources that + provide the specification of the interface + to attach connection points to this VL. See + note. + type: array + items: + description: > + This type contains information related to + a network attachment definition resource + that provides the specification of the + interface used to connect one or multiple + connection points to a secondary + container cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of + being globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated + to this network attachment definition + resource. Shall be present when the + network attachment definition resource + is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to + this network attachment definition + resource. May be present when the + network attachment definition resource + is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + extManagedMultisiteVirtualLinkId: + description: > + An identifier with the intention of being + globally unique. + type: string + routingResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + monitoringParameters: + description: | + Active monitoring parameters. + type: array + items: + description: > + This type represents a monitoring parameter that + is tracked by the VNFM, + type: object + required: + - id + - performanceMetric + properties: + id: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + name: + description: > + Human readable name of the monitoring + parameter, as defined in the VNFD. + type: string + performanceMetric: + description: > + Performance metric that is monitored. This + attribute shall contain the related + "Measurement Name" value as defined in + clause 7.2 of ETSI GS NFV-IFA 027. + type: string + localizationLanguage: + description: > + Information about localization language of the VNF + (includes e.g. strings in the VNFD). The + localization languages supported by a VNF can be + declared in the VNFD, and localization language + selection can take place at instantiation time. + The value shall comply with the format defined in + IETF RFC 5646. + type: string + vnfcResourceInfo: + description: > + Information about the virtualised compute and + storage resources used by the VNFCs of the VNF + instance. + type: array + items: + description: "This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure of\n information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n a) For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n b) For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\nNOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on \n TOSCA specifications.\nNOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an \n internal VL that exposes an external CP. A VNFC CP is \"exposed as\" an external \n CP if it is connected directly to an external VL.\nNOTE 3:\tThe information can be omitted because it is already available as part of the \n external CP information.\nNOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\"\n structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVnfc\" structure in the VNF LCM operation occurrence notifications\n or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\nNOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment\n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. \nNOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n" + type: object + required: + - id + - vduId + - computeResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being + globally unique. + type: string + storageResourceIds: + description: > + References to the VirtualStorage resources + or references to Storage MCIOs. The value + refers to a VirtualStorageResourceInfo item + in the VnfInstance. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfcCpInfo: + description: > + CPs of the VNFC instance. Shall be present + when that particular CP of the VNFC + instance is exposed as an external CP of + the VNF instance or is connected to an + external CP of the VNF instance. See note + 2. May be present otherwise. See note 7. + type: array + items: + type: object + required: + - id + - cpdId + properties: + id: + 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 + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpProtocolInfo: + description: > + Network protocol information for this + CP. May be omitted if the VNFC CP is + exposed as an external CP. See note 3. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + parentCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceInfo” structure that + provides the specification of the + interface to attach the connection point + to a secondary container cluster + network. See notes 5 and 6. It shall be + present if the internal CP is associated + to a VNFC realized by one or a set of OS + containers and is connected to a + secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + certificateContentId: + description: > + Identifier(s) of the + "CertificateContent" structure that + provides the information of the + certificate(s) that this VNFC CP + instance uses. Shall be present when + using in delegation-mode. Otherwise + shall not be present. This attribute + shall be supported when delegation mode + in certificate management is applicable + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this VNFC instance + uses. Shall be present when using in + delegation-mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfVirtualLinkResourceInfo: + description: > + Information about the virtualised network + resources used by the VLs of the VNF instance. See + note 6. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used + by an internal VL instance in a VNF instance. + + Note: If only the value or the presence of this + attribute is changed in the + "VnfVirtualLinkResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires including + a related "AffectedVirtualLink" structure in the VNF LCM operation occurrence notifications or the + "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being + globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfLinkPorts: + description: > + Links ports of this VL. Shall be present + when the linkPort is used for external + connectivity by the VNF (refer to + VnfLinkPortInfo). May be present otherwise. + type: array + items: + description: > + This type represents a link port of an + internal VL of a VNF. + + NOTE 1: Either cpInstanceId with + cpInstanceType set to "EXT_CP" or any + combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 + provides examples for configurations where + both vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is + scoped by the value of "vimConnectionId" + in the "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + virtualStorageResourceInfo: + description: > + Information on the virtualised storage resource(s) + used as storage for the VNF instance. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used + by a VNF instance. + + Note: If only the value or the presence of this + attribute is changed in the + "VirtualStorageResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires + including a related "AffectedVirtualStorage" structure in the VNF LCM operation occurrence + notifications or the "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - virtualStorageDescId + - storageResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being + globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + mcioInfo: + description: > + Information on the MCIO(s) representing VNFC + instance(s) realized by one or a set of OS + containers and created from the same VDU for the + VNF instance. + type: array + items: + description: > + This type provides information about an MCIO + representing the set of VNFC instances realized + by one or a set of OS containers which have + been created based on the same VDU. Within the + CISM, an MCIO controller monitors the actual + state of an MCIO representing the set of VNFC + instances realized by one or a set of OS + containers and compare it to the desired state + For an MCIO related to a VDU that has the + attribute isNumOfInstancesClusterBased set to + FALSE the desired state is specified in the + respective declarative descriptor. For an MCIO + related to a VDU that has the attribute + isNumOfInstancesClusterBased set to TRUE, the + desired state is determined by the number of + CIS-nodes in the cluster that fulfil the VDU + requirements.as specified in the respective + declarative descriptor. It triggers actions + toward the CIS to align the actual to the + desired state. Monitoring the actual state + includes monitoring the number of MCIO instances + available at any specific point in time. In + addition, an MCIO controller maintains + properties and runtime information on the MCIO + instances which have been created based on the + same VDU. The McioInfo data structure provides + the runtime information on the MCIOs obtained + from the MCIO controller. + + NOTE: There are different types of MCIOs. The + set of VNFC instances based on the same VDU is + represented + by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type + of MCIO, e.g. a POD. + + Runtime information of the set of OS containers + realizing an individual VNFC instance is not + part of the McioInfo data structure; such + runtime information is provided in the + ResourceHandle data structure referenced from + the VnfcResourceInfo. The McioInfo does not + provide runtime information of a constituent + VNFC instance created based on a specific VDU. + + NOTE 1: The type of MCIO as specified in the + declarative descriptor of the MCIO, and that can + be read from + the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the + “kind” property of the declarative descriptor. + NOTE 2: If the attribute additionalInfo is + present, it may contain runtime information on + the actual and + desired state of the MCIO(s). + NOTE 3: When the container infrastructure + service is a Kubernetes® instance, the mcioId is + the combined + values from the kind and name fields of the Kubernetes resource object, separated by a slash. + Example: "Deployment/abcd". + NOTE 4: When the container infrastructure + service is a Kubernetes® instance, the mcioName + is the name + field of the resource object. + type: object + required: + - mcioId + - mcioName + - mcioNamespace + - vduId + - cismId + - mcioType + - desiredInstances + - availableInstances + properties: + mcioId: + description: > + An identifier with the intention of being + globally unique. + type: string + mcioName: + description: > + Human readable name of this MCIO. See note + 4. + type: string + mcioNamespace: + description: | + Namespace of this MCIO. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cismId: + description: > + An identifier with the intention of being + globally unique. + type: string + mcioType: + description: > + The type of MCIO. Specific values, their + semantics and associated MCIO types are + defined in clause 5.5.4.9. Additional + values are also permitted. See note 1. + type: string + enum: + - Deployment + - Statefulset + - DaemonSet + desiredInstances: + description: | + Number of desired MCIO instances. + type: integer + availableInstances: + description: | + Number of available MCIO instances. + type: integer + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this MCIO instance + uses. Shall be present when using in + delegation mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfPaasServiceInfo: + description: > + Information on the PaaS Services assigned and used + by the VNF instance. + type: array + items: + description: > + This type provides input information about a + PaaS Service that is used by a VNF instance. The + PaasServiceInfo is comprised of various sets of + information. Some information comes from the + VNFD, other information comes from the PaaS + Service assets provided by the NFVO to the VNFM, + and other information is provided at runtime + information about the usage of the PaaS Service. + type: object + required: + - id + - paasServiceId + - paasServiceType + - paasServiceRequestId + - paasServiceHandle + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being + globally unique. + type: string + paasServiceType: + description: >- + The type of PaaS Service. The value of this + attribute is expected to be matched against + values of the registered PaaS Services in + the PSR. + type: string + paasServiceVersion: + description: | + A version. + type: string + paasServiceRequestId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + paasServiceHandle: + description: > + This type provides information enabling the + access and use of the PaaS Service by the + VNF instance. The type and format of the + handle depends on the form that the PaaS + Service is formed. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + indicators: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + instantiate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + terminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + heal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + operate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + createSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + revertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeCurrentVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperationLinks: + description: > + Links to the most recent LCM operation occurrences + related to this resource. See note 9. + type: object + properties: + recentVnfLcmOperation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmInstantiation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmTerminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmHeal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmModifyInfo: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmCreateSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmRevertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmSelectDplMods: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfcSnapshots: + description: > + Information about VNFC snapshots constituting this VNF + snapshot. + type: array + items: + description: "This type represents a VNFC snapshot.\nNOTE 1:\tThe identifier of the compute snapshot resource is assigned during creation of a VNFC snapshot \n being returned from the VIM as output data in the response message of the individual resource \n operations. This attribute shall only be present for a VNFC snapshot that has been newly created \n by the VNFM as a result of the \"Create VNF snapshot task\".\nNOTE 2:\tThe identifier of the storage snapshot resource is assigned during creation of a VNFC snapshot being \n returned from the VIM as output data in the response message of the individual resource operations. \n This attribute shall only be present for a VNFC snapshot with an associated storage resource and that \n has been newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n" + type: object + required: + - id + - vnfcInstanceId + - triggeredAt + - vnfcResourceId + properties: + id: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + vnfcInstanceId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + creationStartedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + creationFinishedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + vnfcResourceInfoId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + computeSnapshotResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + storageSnapshotResources: + description: > + Mapping of the storage resources associated to the + VNFC with the storage snapshot resources. + type: array + items: + type: object + required: + - storageResourceId + properties: + storageResourceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + storageSnapshotResource: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + userDefinedData: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + vnfStateSnapshotInfo: + description: > + This type represents information about VNF-specific state + snapshot data. + type: object + required: + - checksum + - isEncrypted + properties: + checksum: + description: | + Cheksum description + type: string + isEncrypted: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + userDefinedData: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfStateSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + VnfSnapshotInfoModificationRequest: + description: > + Parameters for the VNF snapshot information modification, as defined in + clause 5.5.2.24. + content: + application/merge-patch+json: + schema: + description: > + This type represents attribute modifications for an "Individual + VNF snapshot" resource, i.e. modifications + + to a resource representation based on the "VnfSnapshotInfo" data + type. The attributes of "VnfSnapshotInfo" + + that can be modified according to the provisions in clause + 5.5.2.22 are included in the + + "VnfSnapshotInfoModificationRequest" data type. + type: object + properties: + vnfSnapshotPkgId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfSnapshot: + description: | + This type represents a VNF snapshot. + type: object + required: + - id + - vnfInstanceId + - triggeredAt + - vnfdId + - vnfInfo + - vnfcSnapshots + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + creationStartedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + creationFinishedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfInstance: + description: "This type represents a VNF instance.\nNOTE:\tClause B.3.2 provides examples illustrating the relationship among the different run-time \n information elements (CP, VL and link ports) used to represent the connectivity of a VNF.\n\nNOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist between \n the previous and the newly referred VNF package, i.e. when the new VNFD is changed with \n respect to the previous VNFD in other aspects than merely referencing to other VNF software \n images. In order to avoid misalignment of the VnfInstance with the current VNF's on-boarded \n VNF Package, the values of attributes in the VnfInstance that have corresponding attributes \n in the VNFD shall be kept in sync with the values in the VNFD.\nNOTE 2:\tETSI GS NFV-SOL 001 [14] specifies the structure and format of the VNFD based on TOSCA specifications. NOTE 3:\tVNF configurable properties are sometimes also referred to as configuration parameters applicable \n to a VNF. Some of these are set prior to instantiation and cannot be modified if the VNF is instantiated, \n some are set prior to instantiation (are part of initial configuration) and can be modified later, \n and others can be set only after instantiation. The applicability of certain configuration may \n depend on the VNF and the required operation of the VNF at a certain point in time.\nNOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes \n of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared in the VNFD with a defined \n initial value. The defined initial values can be declared in the VNFD, and/or, in case of \"metadata\", \n obtained from the \"CreateVnfRequest\" structure. Child attributes of \"vnfConfigurableProperties\", \n \"metadata\" and \"extensions\" that have no defined initial value shall not be created, in order to be \n consistent with the semantics of the JSON Merge Patch method (see IETF RFC 7396) that interprets null \n values as deletion request.\nNOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a \n multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same \n VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed \n multi-site VL instance (refer to clause 5.5.3.3).\nNOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity, they shall \n not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\nNOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing \n the trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\nNOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the \n VNF LCM operation explicitly indicates the scale level for the aspect.\nNOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n" + type: object + required: + - id + - vnfdId + - vnfProvider + - vnfProductName + - vnfSoftwareVersion + - vnfdVersion + - instantiationState + - _links + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceName: + description: > + Name of the VNF instance. This attribute can be + modified with the PATCH method. + type: string + vnfInstanceDescription: + description: > + Human-readable description of the VNF instance. This + attribute can be modified with the PATCH method. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProvider: + description: > + Provider of the VNF and the VNFD. The value is copied + from the VNFD. + type: string + vnfProductName: + description: > + Name to identify the VNF Product. The value is copied + from the VNFD. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + vimConnectionInfo: + description: > + Information about VIM or CISM connections to be used + for managing the resources for the VNF instance. The + keys of the map, each of which identifies information + about a particular VIM connection, are managed by the + NFVO and referenced from other data structures via the + "vimConnectionId" attribute. This attribute shall only + be supported and present if - the resources of at + least of the VNFCs are managed by a VIM and + VNF-related resource management in direct mode is + applicable. - the resources of at least of the VNFCs + are managed by a CISM. This attribute can be modified + with the PATCH method. If VIM connection information + is provisioned to the VNFM by means outside the scope + of the present document, the information in the + "vimConnectionInfo" attribute provides necessary + information for binding the VnfInstance representing + the "Individual VNF instance" to the applicable VIM + connection information used to perform resource + management for the VNF instance. See also the + definition of the "VimConnectionInfo" in clause + 4.4.1.6. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being + globally unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute + determines the structure of the "interfaceInfo" + and "accessInfo" attributes, based on the type + of the VIM., CISM, CIR or MCIOP repository. The + set of permitted values is expected to change + over time as new types or versions of VIMs + become available. The ETSI NFV registry of + VIM-related information provides access to + information about VimConnectionInfo definitions + for various VIM, CISM, CIR or MCIOP repository + types. The structure of the registry is defined + in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + cirConnectionInfo: + description: > + Information about the CIR connection for managing OS + container images for the VNF instance. Shall be + present when all or part of the VNF is realized by a + set of OS containers and shall be absent otherwise. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being + globally unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute + determines the structure of the "interfaceInfo" + and "accessInfo" attributes, based on the type + of the VIM., CISM, CIR or MCIOP repository. The + set of permitted values is expected to change + over time as new types or versions of VIMs + become available. The ETSI NFV registry of + VIM-related information provides access to + information about VimConnectionInfo definitions + for various VIM, CISM, CIR or MCIOP repository + types. The structure of the registry is defined + in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + mciopRepositoryInfo: + description: > + Information about the MCIOP repository for the VNF + instance. Shall be present when all or part of the VNF + is realized by a set of OS containers and shall be + absent otherwise. See note 1. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being + globally unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute + determines the structure of the "interfaceInfo" + and "accessInfo" attributes, based on the type + of the VIM., CISM, CIR or MCIOP repository. The + set of permitted values is expected to change + over time as new types or versions of VIMs + become available. The ETSI NFV registry of + VIM-related information provides access to + information about VimConnectionInfo definitions + for various VIM, CISM, CIR or MCIOP repository + types. The structure of the registry is defined + in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + certificateInfo: + description: > + This type provides input information related to + certificate and certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + certificateConfigurationInfo: + description: > + This type provides input information related to + certificate management. + type: object + required: + - securityPolicy + properties: + certificateBaseProfile: + description: Information for certificate profile. + type: array + items: + description: > + NOTE: At least one overriding attributes + shall be present, otherwise shall be absent. + + This type provides input information to + override certificate base profile for + certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + issuer: + description: Issuer of certificates. See note. + type: string + issuerUniqueIdentifier: + description: > + An identifier with the intention of + being globally unique. + type: string + subject: + description: > + This type provides input information + related to the subject of the + certificate. + + NOTE: At least one overriding attributes + shall be present, otherwise shall be + absent. + type: object + properties: + commonName: + description: > + Information of the certification target + subject FQDN. Can be set empty when this + certificate is used for encrypted + communication using IP address. See + note. + type: string + organization: + description: >- + Information of the certification target + subject Organization. See note. + type: string + country: + description: >- + Information of the certification target + subject Country. See note. + type: string + state: + description: >- + Information of the certification target + subject State. See note. + type: string + locality: + description: >- + Information of the certification target + subject Locality. See note. + type: string + emailAddress: + description: >- + Information of the certification contact + email address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of + being globally unique. + type: string + basicConstraints: + description: >- + Basic constraints of certificates. See + note. + type: string + issuerAltName: + description: >- + Alternative name of issuer of + certificates in this NS. See note. + type: array + items: + type: string + subjectAltName: + description: > + Alternative name of subject of + certificates. Shall be present when this + certificate is used for encrypted + communication using IP address and + subjectAltName attribute of + CertificateBaseProfile in + CertificateDesc of VNFD is empty (see + ETSI GS NFV-IFA 011 [14], clause + 7.1.19.4). See note. + type: array + items: + type: string + nameConstraints: + description: >- + Name constraints of certificates. See + note. + type: array + items: + type: string + securityPolicy: + description: >- + Information for security policy to be + satisfied for certificate. + type: array + items: + description: > + This type provides input information related + to security policy for certificate + management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + maxValidityPeriod: + description: >- + Allowed max validity period for + certificates. + type: number + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: number + delegationSupportedCertificateManagements: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + cmfInfo: + description: > + This type provides input information related + to CMF for certificate management. + type: object + required: + - id + - endPoint + - supportedProtocol + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + endPoint: + description: End point of CMF instance. + type: object + properties: + 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 + link: + description: > + This type represents a link to a + resource using an absolute URI. + type: object + required: + - href + properties: + href: + description: > + String formatted according to IETF RFC + 3986. + type: string + supportedProtocol: + description: Supported protocols by CMF instance. + type: array + items: + description: Supported protocol by CMF instance. + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + certificateChain: + description: Certificate chain that this CMF provides. + type: array + items: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + certificateContents: + description: > + Information for contents of issued certificates. + The information contained in this attribute may be + updated over time during the VNF LCM, e.g., + certificate(s) renewal. + type: array + items: + description: > + This type provides input information related to + certificate content. + + NOTE: The CertificateDesc data type is defined + in clause 7.1.19.2 of ETSI GS NFV IFA 011 [10]. + type: object + required: + - id + - certificateDescId + - certificateType + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + certificateDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + certificateType: + description: Type of this certificate. + type: string + enum: + - VNFCI_CERT + - VNFOAM_CERT + supportedCertificateManagements: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + version: + description: | + A version. + type: string + serialNumber: + description: Serial number of this certificate. + type: integer + signatureAlgorithm: + description: Algorithm of this certificate's signature. + type: string + issuer: + description: Issuer of this certificate. + type: string + notBefore: + description: > + Date-time stamp. Representation: String + formatted according to IETF RFC 3339. + type: string + format: date-time + notAfter: + description: > + Date-time stamp. Representation: String + formatted according to IETF RFC 3339. + type: string + format: date-time + subject: + description: Subject of this certificate. + type: string + publicKeyAlgorithm: + description: Algorithm of this certificate's public key. + type: string + publicKey: + description: Public key of this certificate. + type: string + certificateExtensions: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + instantiationState: + description: > + The instantiation state of the VNF. Permitted values: + - NOT_INSTANTIATED: The VNF instance is terminated or + not instantiated. - INSTANTIATED: The VNF instance is + instantiated. + type: string + enum: + - NOT_INSTANTIATED + - INSTANTIATED + instantiatedVnfInfo: + description: > + Information specific to an instantiated VNF instance. + This attribute shall be present if the + instantiateState attribute value is INSTANTIATED. + type: object + required: + - flavourId + - vnfState + properties: + flavourId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfState: + description: > + STARTED: The VNF instance is up and running. + STOPPED: The VNF instance has been shut down. + type: string + enum: + - STARTED + - STOPPED + vnfPowerState: + description: > + This type represents information about the power + state of a VNF instance. + type: object + required: + - powerProfileId + - name + properties: + powerProfileId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + name: + description: > + Name of the power profile as provided in the + VNFD. + type: string + powerConsumptionInfo: + description: > + This type represents information about + estimated power consumption of the resources + associated with the power profile, as provided + in the VNFD. + type: object + required: + - minPowerConsumption + - maxPowerConsumption + - averagePowerConsumption + properties: + minPowerConsumption: + description: > + Minimum power consumption of this power + profile. Unit is KW/h. + type: integer + maxPowerConsumption: + description: > + Maximum power consumption of this power + profile. Unit is KW/h. + type: integer + averagePowerConsumption: + description: > + Average power consumption of this power + profile. Unit is KW/h. + type: integer + scaleStatus: + description: > + Scale status of the VNF, one entry per aspect. + Represents for every scaling aspect how "big" the + VNF has been scaled w.r.t. that aspect. + + This attribute shall be present if the VNF + supports scaling. See clause B.2 for an + explanation of VNF scaling. + + For an aspect that has not been deployed because + the related deployableModule has not been + selected, it indicates the scale level that has + been requested in the instantiation or in a + scaling operation, or, if none has been requested + in any of them, the scale level applicable to the + aspect based on the default instantiation level. + See note 8. + type: array + items: + description: > + This type represents the scale level of a VNF + instance related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being + globally unique. + type: string + maxScaleLevels: + description: > + Maximum allowed scale levels of the VNF, one entry + per aspect. This attribute shall be present if the + VNF supports scaling. + type: array + items: + description: > + This type represents the scale level of a VNF + instance related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being + globally unique. + type: string + selectedDeployableModule: + description: > + References a currently selected deployable module, + as defined in the VNFD, that has already + completed the instantiation of its VNFCs. + type: array + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + resourceCapacityDefinition: + description: > + Shows current values of VDU attributes related to + resource capacity, if different to the default + values from the VNFD, as indicated in the (one or + more) request(s) of all completed VNF LCM + operation(s) that contain this attribute. If an + attribute value has been modified multiple times, + only the last value is shown. The values indicated + in this attribute are applicable to all VNFC + instances based on the VDU to which the + resourceCapacityDefinition is related. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes. + + * NOTE: Resource definitions not related to a + VDU are not considered in this version of the + present document. + type: object + required: + - type + properties: + tag: + description: > + Tag assigned by the issuer of a VNF LCM + operation request that contains this data + type with values to be applied to a VDU. It + is used for tracking purposes. + + The tag is preserved in the run time record + as long as at least one value of the + capacity related attributes associated with + that tag is still valid, i.e., it has not + been modified by a later VNF LCM operation + request. + + At most one tag can be included when the + data type is used in a VNF LCM operation + request. + + When the data type is used in the + VnfInstance data type it may contain + multiple tags, namely those provided in VNF + LCM requests, if at least one of the values + provided in that request associated to that + tag is still applicable in the VNFCs created + from this VDU, i.e., it has not been + modified by a later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: | + Type of the resource definition referenced. + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + osContainerDescData: + description: > + Indicates values for resource capacity + related attributes in an OsContainerDesc. + It shall be present when the attribute + 'type' indicates OSCONTAINER and absent + otherwise. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes of an + OsContainer resource. + + * NOTE: At least one of the attributes + shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for + the container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for + the container expressed in the same + units as specified in the + requested_memory_resources_valid_values + property in VNFD (clause 6.8.12 in ETSI + GS NFV-SOL 001 [14]) for this container + descriptor. See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources + of the type indicated in the key. The + key is a string that identifies an + extended resource indicated in the + extended_resource_requests property in + the VNFD (clause 6.8.12 in ETSI GS + NFV-SOL 001 [14]) for this container + descriptor. The value is an integer that + indicates the required amount for a + particular extended resource. See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container + can maximally use in milli-CPU. See + note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required + for all the hugepages of the size + indicated in the key. The key is a + string and corresponds to one of the + values of the hugepage sizes indicated + in the huge_pages_resources property in + the VNFD (clause 6.8.12 in ETSI GS + NFV-SOL 001 [14]) for this container + descriptor. The value is a number that + indicates the required total size + expressed in the same units as in the + huge_pages_resource property in the VNFD + (clause 6.8.12 in ETSI GS NFV-SOL 001 + [14]) that indicates the valid values + for required total size for the + particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power + state configuration data for the virtual + compute or OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU + cores are requested to be allocated to + logical CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states + of virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on + core utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for + capacity related VDU attributes of the + virtual compute resource of a VM. + + * NOTE: At least one of the attributes shall + be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required + for all the hugepages of the size + indicated in the key. The key is a + string and corresponds to one of the + values of the hugepage sizes indicated + in the huge_pages_requirements property + in the VNFD (clause 6.2.7.2 in ETSI GS + NFV-SOL 001 [14]) for this virtual + compute descriptor. The value is a + numberthat indicates the required total + size expressed in the same units as in + the huge_pages_requirements property in + the VNFD (clause 6.2.7.2 in ETSI GS + NFV-SOL 001 [14]) that indicates the + valid vaues for required total size for + the particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power + state configuration data for the virtual + compute or OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU + cores are requested to be allocated to + logical CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states + of virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on + core utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size + related attribute in an VirtualStorageDesc. + It shall be present when the attribute + 'type' indicates STORAGE and absent + otherwise. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes of the + virtual storage resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + extCpInfo: + description: > + Information about the external CPs exposed by the + VNF instance. When trunking is enabled, the list + of entries includes both, external CPs + corresponding to parent ports of a trunk, and + external CPs associated to sub-ports of a + trunk.See note 7. + type: array + items: + description: "This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n" + type: object + required: + - id + - cpdId + - cpConfigId + - cpProtocolInfo + oneOf: + - required: + - associatedVnfcCpId + - required: + - associatedVipCpId + - required: + - associatedVnfVirtualLinkId + properties: + id: + 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 + cpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolInfo: + description: | + Network protocol information for this CP. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + extLinkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + associatedVnfcCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVipCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVirtualCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVnfVirtualLinkId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceInfo” + structure that provides the specification of + the interface to attach the connection point + to a secondary container cluster network. + See notes 3 and 4. + + It shall be present if the external CP is + associated to a VNFC realized by one or a + set of OS containers and is connected to a + secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this VNF CP + instance uses. Shall be present when using + in delegation-mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + cpSecurityGroupInfo: + description: > + This type provides the list of active + security group rules applied to an external + CP instance. The type identifies which + "SecurityGroupRule" specified in the VNFD + are activated and the values of its + attributes. + type: object + required: + - securityGroupRuleId + - etherType + - protocol + - portRangeMin + - portRangeMax + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + description: + description: > + Human readable description of the + security group rule. + type: string + etherType: + description: > + Indicates the protocol carried over the + Ethernet layer. Permitted values: IPV4, + IPV6. + type: string + enum: + - IPV4 + - IPV6 + protocol: + description: > + Indicates the protocol carried over the + IP layer. Permitted values: any protocol + defined in the IANA protocol registry + (refer to clause 9.10.1.2 ofd ETSI GS + NFV-SOL 001 for further information). + type: string + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. + type: integer + vipCpInfo: + description: > + VIP CPs that are part of the VNF instance. Shall + be present when that particular VIP CP of the VNFC + instance is associated to an external CP of the + VNF instance. May be present otherwise. + type: array + minItems: 1 + items: + description: "This type provides information related to virtual IP (VIP) CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n" + type: object + required: + - cpInstanceId + - cpdId + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There + shall be one cpProtocolInfo for layer 3. + There may be one cpProtocolInfo for layer 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + associatedVnfcCpIds: + description: > + Identifiers of the VnfcCps that share the + virtual IP address allocated to the VIP CP + instance. See note. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + virtualCpInfo: + description: > + Virtual CPs that are part of the VNF instance. + Shall be present when a particular Virtual CP is + associated to an external CP of the VNF instance. + May be present otherwise. + type: array + items: + description: > + This type provides information related to a + virtual CP instance of a VNF. + + NOTE 1: A consumer of the VNF LCM interface can + learn the actual VNFC instances implementing the + service + accessible via the virtual CP instance by querying the "vnfcResourceInfo" from the "InstantiatedVnfInfo" + and filtering by corresponding "vduIds" values. + NOTE 2: The information can be omitted because + it is already available as part of the external + CP information in the + VnfExtCpInfo structure. + type: object + required: + - cpInstanceId + - cpdId + - resourceHandle + - vduIds + properties: + cpInstanceId: + 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 + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There + shall be one cpProtocolInfo for each layer + protocol supported. This attribute may be + omitted if the virtual CP is exposed as an + external CP. See note 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vduIds: + description: > + Reference to the VDU(s) which implement the + service accessible via the virtual CP + instance. See note 1. + type: array + minItems: 1 + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + additionalServiceInfo: + description: > + Additional service identification + information of the virtual CP instance. + type: array + items: + description: > + This type provides additional service + information of the virtual CP instance + used to expose properties of the virtual + CP to NFV-MANO. + + NOTE: This attribute shall only be present + if additional information is needed to + identify the service + termination within the VNF, such as for example a URL path information in an HTTP request required + to allow a single virtual CP IP address to be used for several HTTP based services that use the + same port number. + type: object + required: + - portInfo + properties: + portInfo: + description: > + Service port numbers exposed by the + virtual CP instance. + minItems: 1 + type: array + items: + description: > + This type describes the service + identifying port properties exposed by + the virtual CP instance. + type: object + required: + - name + - port + - portConfigurable + properties: + name: + description: > + The name of the port exposed by the + virtual CP instance. + type: string + protocol: + description: > + The L4 protocol for this port exposed by + the virtual CP instance. + + Permitted values: - TCP - UDP - SCTP + type: string + enum: + - TCP + - UDP + - SCTP + port: + description: > + The L4 port number exposed by the + virtual CP instance. + type: integer + portConfigurable: + description: > + The Boolean is a data type having two + values (true and false). + type: boolean + serviceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + extVirtualLinkInfo: + description: > + Information about the external VLs the VNF + instance is connected to. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the current + CP configuration information for the + connection of external CPs to the external + virtual link. See note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be + configured on the CP instances created + from the respective CPD. + + The key of the map which identifies the + individual VnfExtCpConfig entries is of + type "IdentifierInVnf" and is managed by + the NFVO. + + The entries shall be applied by the VNFM + according to the rules of JSON Merge + Patch (see IETF RFC 7396). See notes 2, + 3, 4, 5, 6. In case of deleting an + external CP, the list of instances to be + deleted. + type: object + additionalProperties: + description: > + This type represents an externally + provided link port, or a network + attachment definition resource of + secondary container cluster network, or + network address information per instance + of an external connection point. In the + case of VM-based deployment of the VNFC + exposing the external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based + deployment of the VNFC exposing the + external CP, the VNFM shall use the + network attachment definition resource + of secondary container cluster network + when connecting the CP to the external + VL. + + * NOTE 1: The following conditions apply + to the attributes "linkPortId" and + "cpProtocolData" for an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply + to the attributes “netAttDefResourceId” + and “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is + only applicable for specific cases where + more than one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but + not both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of + being globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create + a dedicated link port for the external + CP. If set to True, the VNFM shall + create a link port. If set to False, the + VNFM shall not create a link port. This + attribute is only applicable for + external CP instances without a floating + IP address that expose a VIP CP instance + for which a dedicated IP address is + allocated. It shall be present in that + case and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceData” structure that + provides the specification of the + interface to attach the external CP to a + secondary container cluster network. It + is only applicable if the external CP is + connected or to be connected to a + secondary container cluster network. It + shall not be present if the external CP + is related to a virtual network not + categorized as secondary container + cluster network. See notes 2, 3 and 4. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects + the CP to a VL and the domain names for + the external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security + groups. The parameters identify which + "SecurityGroupRule" specified in the + VNFD is activated/deactivated and for an + activated security group rule the values + of attributes defined in the VNFD that + can be overriden such as "portRangeMin" + and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extNetAttDefResource: + description: > + Network attachment definition resources that + provide the specification of the interface + to attach connection points to this VL. + type: array + items: + description: > + This type contains information related to + a network attachment definition resource + that provides the specification of the + interface used to connect one or multiple + connection points to a secondary + container cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of + being globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated + to this network attachment definition + resource. Shall be present when the + network attachment definition resource + is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to + this network attachment definition + resource. May be present when the + network attachment definition resource + is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and + been associated to the CP. + type: array + items: + type: string + extManagedVirtualLinkInfo: + description: > + Information about the externally-managed internal + VLs of the VNF instance. See notes 5 and 6. + type: array + items: + description: > + This type provides information about an + externally-managed virtual link. Note: Both + "vnfLinkPort" and "vnfNetAttDefResource" + attributes can be present in an + "ExtManagedVirtualLinkInfo" to + indicate that a single internal virtual link is providing connectivity for both VM-based and container-based + VNFCs. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + vnfLinkPorts: + description: | + Link ports of this VL. See note. + type: array + items: + description: > + This type represents a link port of an + internal VL of a VNF. + + NOTE 1: Either cpInstanceId with + cpInstanceType set to "EXT_CP" or any + combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 + provides examples for configurations where + both vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is + scoped by the value of "vimConnectionId" + in the "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vnfNetAttDefResource: + description: > + Network attachment definition resources that + provide the specification of the interface + to attach connection points to this VL. See + note. + type: array + items: + description: > + This type contains information related to + a network attachment definition resource + that provides the specification of the + interface used to connect one or multiple + connection points to a secondary + container cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of + being globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated + to this network attachment definition + resource. Shall be present when the + network attachment definition resource + is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to + this network attachment definition + resource. May be present when the + network attachment definition resource + is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + extManagedMultisiteVirtualLinkId: + description: > + An identifier with the intention of being + globally unique. + type: string + routingResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + monitoringParameters: + description: | + Active monitoring parameters. + type: array + items: + description: > + This type represents a monitoring parameter that + is tracked by the VNFM, + type: object + required: + - id + - performanceMetric + properties: + id: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + name: + description: > + Human readable name of the monitoring + parameter, as defined in the VNFD. + type: string + performanceMetric: + description: > + Performance metric that is monitored. This + attribute shall contain the related + "Measurement Name" value as defined in + clause 7.2 of ETSI GS NFV-IFA 027. + type: string + localizationLanguage: + description: > + Information about localization language of the VNF + (includes e.g. strings in the VNFD). The + localization languages supported by a VNF can be + declared in the VNFD, and localization language + selection can take place at instantiation time. + The value shall comply with the format defined in + IETF RFC 5646. + type: string + vnfcResourceInfo: + description: > + Information about the virtualised compute and + storage resources used by the VNFCs of the VNF + instance. + type: array + items: + description: "This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure of\n information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n a) For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n b) For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\nNOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on \n TOSCA specifications.\nNOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an \n internal VL that exposes an external CP. A VNFC CP is \"exposed as\" an external \n CP if it is connected directly to an external VL.\nNOTE 3:\tThe information can be omitted because it is already available as part of the \n external CP information.\nNOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\"\n structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVnfc\" structure in the VNF LCM operation occurrence notifications\n or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\nNOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment\n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. \nNOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n" + type: object + required: + - id + - vduId + - computeResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being + globally unique. + type: string + storageResourceIds: + description: > + References to the VirtualStorage resources + or references to Storage MCIOs. The value + refers to a VirtualStorageResourceInfo item + in the VnfInstance. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfcCpInfo: + description: > + CPs of the VNFC instance. Shall be present + when that particular CP of the VNFC + instance is exposed as an external CP of + the VNF instance or is connected to an + external CP of the VNF instance. See note + 2. May be present otherwise. See note 7. + type: array + items: + type: object + required: + - id + - cpdId + properties: + id: + 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 + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpProtocolInfo: + description: > + Network protocol information for this + CP. May be omitted if the VNFC CP is + exposed as an external CP. See note 3. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + parentCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceInfo” structure that + provides the specification of the + interface to attach the connection point + to a secondary container cluster + network. See notes 5 and 6. It shall be + present if the internal CP is associated + to a VNFC realized by one or a set of OS + containers and is connected to a + secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + certificateContentId: + description: > + Identifier(s) of the + "CertificateContent" structure that + provides the information of the + certificate(s) that this VNFC CP + instance uses. Shall be present when + using in delegation-mode. Otherwise + shall not be present. This attribute + shall be supported when delegation mode + in certificate management is applicable + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this VNFC instance + uses. Shall be present when using in + delegation-mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfVirtualLinkResourceInfo: + description: > + Information about the virtualised network + resources used by the VLs of the VNF instance. See + note 6. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used + by an internal VL instance in a VNF instance. + + Note: If only the value or the presence of this + attribute is changed in the + "VnfVirtualLinkResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires including + a related "AffectedVirtualLink" structure in the VNF LCM operation occurrence notifications or the + "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being + globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfLinkPorts: + description: > + Links ports of this VL. Shall be present + when the linkPort is used for external + connectivity by the VNF (refer to + VnfLinkPortInfo). May be present otherwise. + type: array + items: + description: > + This type represents a link port of an + internal VL of a VNF. + + NOTE 1: Either cpInstanceId with + cpInstanceType set to "EXT_CP" or any + combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 + provides examples for configurations where + both vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is + scoped by the value of "vimConnectionId" + in the "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + virtualStorageResourceInfo: + description: > + Information on the virtualised storage resource(s) + used as storage for the VNF instance. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used + by a VNF instance. + + Note: If only the value or the presence of this + attribute is changed in the + "VirtualStorageResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires + including a related "AffectedVirtualStorage" structure in the VNF LCM operation occurrence + notifications or the "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - virtualStorageDescId + - storageResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being + globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + mcioInfo: + description: > + Information on the MCIO(s) representing VNFC + instance(s) realized by one or a set of OS + containers and created from the same VDU for the + VNF instance. + type: array + items: + description: > + This type provides information about an MCIO + representing the set of VNFC instances realized + by one or a set of OS containers which have + been created based on the same VDU. Within the + CISM, an MCIO controller monitors the actual + state of an MCIO representing the set of VNFC + instances realized by one or a set of OS + containers and compare it to the desired state + For an MCIO related to a VDU that has the + attribute isNumOfInstancesClusterBased set to + FALSE the desired state is specified in the + respective declarative descriptor. For an MCIO + related to a VDU that has the attribute + isNumOfInstancesClusterBased set to TRUE, the + desired state is determined by the number of + CIS-nodes in the cluster that fulfil the VDU + requirements.as specified in the respective + declarative descriptor. It triggers actions + toward the CIS to align the actual to the + desired state. Monitoring the actual state + includes monitoring the number of MCIO instances + available at any specific point in time. In + addition, an MCIO controller maintains + properties and runtime information on the MCIO + instances which have been created based on the + same VDU. The McioInfo data structure provides + the runtime information on the MCIOs obtained + from the MCIO controller. + + NOTE: There are different types of MCIOs. The + set of VNFC instances based on the same VDU is + represented + by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type + of MCIO, e.g. a POD. + + Runtime information of the set of OS containers + realizing an individual VNFC instance is not + part of the McioInfo data structure; such + runtime information is provided in the + ResourceHandle data structure referenced from + the VnfcResourceInfo. The McioInfo does not + provide runtime information of a constituent + VNFC instance created based on a specific VDU. + + NOTE 1: The type of MCIO as specified in the + declarative descriptor of the MCIO, and that can + be read from + the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the + “kind” property of the declarative descriptor. + NOTE 2: If the attribute additionalInfo is + present, it may contain runtime information on + the actual and + desired state of the MCIO(s). + NOTE 3: When the container infrastructure + service is a Kubernetes® instance, the mcioId is + the combined + values from the kind and name fields of the Kubernetes resource object, separated by a slash. + Example: "Deployment/abcd". + NOTE 4: When the container infrastructure + service is a Kubernetes® instance, the mcioName + is the name + field of the resource object. + type: object + required: + - mcioId + - mcioName + - mcioNamespace + - vduId + - cismId + - mcioType + - desiredInstances + - availableInstances + properties: + mcioId: + description: > + An identifier with the intention of being + globally unique. + type: string + mcioName: + description: > + Human readable name of this MCIO. See note + 4. + type: string + mcioNamespace: + description: | + Namespace of this MCIO. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cismId: + description: > + An identifier with the intention of being + globally unique. + type: string + mcioType: + description: > + The type of MCIO. Specific values, their + semantics and associated MCIO types are + defined in clause 5.5.4.9. Additional + values are also permitted. See note 1. + type: string + enum: + - Deployment + - Statefulset + - DaemonSet + desiredInstances: + description: | + Number of desired MCIO instances. + type: integer + availableInstances: + description: | + Number of available MCIO instances. + type: integer + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this MCIO instance + uses. Shall be present when using in + delegation mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfPaasServiceInfo: + description: > + Information on the PaaS Services assigned and used + by the VNF instance. + type: array + items: + description: > + This type provides input information about a + PaaS Service that is used by a VNF instance. The + PaasServiceInfo is comprised of various sets of + information. Some information comes from the + VNFD, other information comes from the PaaS + Service assets provided by the NFVO to the VNFM, + and other information is provided at runtime + information about the usage of the PaaS Service. + type: object + required: + - id + - paasServiceId + - paasServiceType + - paasServiceRequestId + - paasServiceHandle + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being + globally unique. + type: string + paasServiceType: + description: >- + The type of PaaS Service. The value of this + attribute is expected to be matched against + values of the registered PaaS Services in + the PSR. + type: string + paasServiceVersion: + description: | + A version. + type: string + paasServiceRequestId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + paasServiceHandle: + description: > + This type provides information enabling the + access and use of the PaaS Service by the + VNF instance. The type and format of the + handle depends on the form that the PaaS + Service is formed. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + indicators: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + instantiate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + terminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + heal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + operate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + createSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + revertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeCurrentVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperationLinks: + description: > + Links to the most recent LCM operation occurrences + related to this resource. See note 9. + type: object + properties: + recentVnfLcmOperation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmInstantiation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmTerminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmHeal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmModifyInfo: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmCreateSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmRevertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmSelectDplMods: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfcSnapshots: + description: > + Information about VNFC snapshots constituting this VNF + snapshot. + type: array + items: + description: "This type represents a VNFC snapshot.\nNOTE 1:\tThe identifier of the compute snapshot resource is assigned during creation of a VNFC snapshot \n being returned from the VIM as output data in the response message of the individual resource \n operations. This attribute shall only be present for a VNFC snapshot that has been newly created \n by the VNFM as a result of the \"Create VNF snapshot task\".\nNOTE 2:\tThe identifier of the storage snapshot resource is assigned during creation of a VNFC snapshot being \n returned from the VIM as output data in the response message of the individual resource operations. \n This attribute shall only be present for a VNFC snapshot with an associated storage resource and that \n has been newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n" + type: object + required: + - id + - vnfcInstanceId + - triggeredAt + - vnfcResourceId + properties: + id: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + vnfcInstanceId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + creationStartedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + creationFinishedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + vnfcResourceInfoId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + computeSnapshotResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + storageSnapshotResources: + description: > + Mapping of the storage resources associated to the + VNFC with the storage snapshot resources. + type: array + items: + type: object + required: + - storageResourceId + properties: + storageResourceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + storageSnapshotResource: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + userDefinedData: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + vnfStateSnapshotInfo: + description: > + This type represents information about VNF-specific state + snapshot data. + type: object + required: + - checksum + - isEncrypted + properties: + checksum: + description: | + Cheksum description + type: string + isEncrypted: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + userDefinedData: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfStateSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + responses: + VNFInstances.Post.201: + description: > + 201 CREATED + + + Shall be returned when a new "Individual VNF instance" resource and + + the associated VNF instance identifier washas been created successfully. + + The response body shall contain a representation of the created VNF + instance, + + as defined in clause 5.5.2.2. + + The HTTP response shall include a "Location" HTTP header that contains + the resource + + URI of the created VNF instance. + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: "This type represents a VNF instance.\nNOTE:\tClause B.3.2 provides examples illustrating the relationship among the different run-time \n information elements (CP, VL and link ports) used to represent the connectivity of a VNF.\n\nNOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist between \n the previous and the newly referred VNF package, i.e. when the new VNFD is changed with \n respect to the previous VNFD in other aspects than merely referencing to other VNF software \n images. In order to avoid misalignment of the VnfInstance with the current VNF's on-boarded \n VNF Package, the values of attributes in the VnfInstance that have corresponding attributes \n in the VNFD shall be kept in sync with the values in the VNFD.\nNOTE 2:\tETSI GS NFV-SOL 001 [14] specifies the structure and format of the VNFD based on TOSCA specifications. NOTE 3:\tVNF configurable properties are sometimes also referred to as configuration parameters applicable \n to a VNF. Some of these are set prior to instantiation and cannot be modified if the VNF is instantiated, \n some are set prior to instantiation (are part of initial configuration) and can be modified later, \n and others can be set only after instantiation. The applicability of certain configuration may \n depend on the VNF and the required operation of the VNF at a certain point in time.\nNOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes \n of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared in the VNFD with a defined \n initial value. The defined initial values can be declared in the VNFD, and/or, in case of \"metadata\", \n obtained from the \"CreateVnfRequest\" structure. Child attributes of \"vnfConfigurableProperties\", \n \"metadata\" and \"extensions\" that have no defined initial value shall not be created, in order to be \n consistent with the semantics of the JSON Merge Patch method (see IETF RFC 7396) that interprets null \n values as deletion request.\nNOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a \n multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same \n VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed \n multi-site VL instance (refer to clause 5.5.3.3).\nNOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity, they shall \n not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\nNOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing \n the trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\nNOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the \n VNF LCM operation explicitly indicates the scale level for the aspect.\nNOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n" + type: object + required: + - id + - vnfdId + - vnfProvider + - vnfProductName + - vnfSoftwareVersion + - vnfdVersion + - instantiationState + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfInstanceName: + description: > + Name of the VNF instance. This attribute can be modified with + the PATCH method. + type: string + vnfInstanceDescription: + description: > + Human-readable description of the VNF instance. This attribute + can be modified with the PATCH method. + type: string + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfProvider: + description: > + Provider of the VNF and the VNFD. The value is copied from the + VNFD. + type: string + vnfProductName: + description: > + Name to identify the VNF Product. The value is copied from the + VNFD. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + vimConnectionInfo: + description: > + Information about VIM or CISM connections to be used for + managing the resources for the VNF instance. The keys of the + map, each of which identifies information about a particular + VIM connection, are managed by the NFVO and referenced from + other data structures via the "vimConnectionId" attribute. + This attribute shall only be supported and present if - the + resources of at least of the VNFCs are managed by a VIM and + VNF-related resource management in direct mode is applicable. + - the resources of at least of the VNFCs are managed by a + CISM. This attribute can be modified with the PATCH method. If + VIM connection information is provisioned to the VNFM by means + outside the scope of the present document, the information in + the "vimConnectionInfo" attribute provides necessary + information for binding the VnfInstance representing the + "Individual VNF instance" to the applicable VIM connection + information used to perform resource management for the VNF + instance. See also the definition of the "VimConnectionInfo" + in clause 4.4.1.6. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines the + structure of the "interfaceInfo" and "accessInfo" + attributes, based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values is + expected to change over time as new types or versions of + VIMs become available. The ETSI NFV registry of + VIM-related information provides access to information + about VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The structure of + the registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + cirConnectionInfo: + description: > + Information about the CIR connection for managing OS container + images for the VNF instance. Shall be present when all or part + of the VNF is realized by a set of OS containers and shall be + absent otherwise. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines the + structure of the "interfaceInfo" and "accessInfo" + attributes, based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values is + expected to change over time as new types or versions of + VIMs become available. The ETSI NFV registry of + VIM-related information provides access to information + about VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The structure of + the registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + mciopRepositoryInfo: + description: > + Information about the MCIOP repository for the VNF instance. + Shall be present when all or part of the VNF is realized by a + set of OS containers and shall be absent otherwise. See note + 1. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines the + structure of the "interfaceInfo" and "accessInfo" + attributes, based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values is + expected to change over time as new types or versions of + VIMs become available. The ETSI NFV registry of + VIM-related information provides access to information + about VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The structure of + the registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + certificateInfo: + description: > + This type provides input information related to certificate + and certificate management. + type: object + required: + - id + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + certificateConfigurationInfo: + description: > + This type provides input information related to + certificate management. + type: object + required: + - securityPolicy + properties: + certificateBaseProfile: + description: Information for certificate profile. + type: array + items: + description: > + NOTE: At least one overriding attributes shall be + present, otherwise shall be absent. + + This type provides input information to override + certificate base profile for certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + issuer: + description: Issuer of certificates. See note. + type: string + issuerUniqueIdentifier: + description: > + An identifier with the intention of being + globally unique. + type: string + subject: + description: > + This type provides input information related to + the subject of the certificate. + + NOTE: At least one overriding attributes shall + be present, otherwise shall be absent. + type: object + properties: + commonName: + description: > + Information of the certification target + subject FQDN. Can be set empty when this + certificate is used for encrypted + communication using IP address. See note. + type: string + organization: + description: >- + Information of the certification target + subject Organization. See note. + type: string + country: + description: >- + Information of the certification target + subject Country. See note. + type: string + state: + description: >- + Information of the certification target + subject State. See note. + type: string + locality: + description: >- + Information of the certification target + subject Locality. See note. + type: string + emailAddress: + description: >- + Information of the certification contact + email address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of being + globally unique. + type: string + basicConstraints: + description: Basic constraints of certificates. See note. + type: string + issuerAltName: + description: >- + Alternative name of issuer of certificates in + this NS. See note. + type: array + items: + type: string + subjectAltName: + description: > + Alternative name of subject of certificates. + Shall be present when this certificate is used + for encrypted communication using IP address and + subjectAltName attribute of + CertificateBaseProfile in CertificateDesc of + VNFD is empty (see ETSI GS NFV-IFA 011 [14], + clause 7.1.19.4). See note. + type: array + items: + type: string + nameConstraints: + description: Name constraints of certificates. See note. + type: array + items: + type: string + securityPolicy: + description: >- + Information for security policy to be satisfied for + certificate. + type: array + items: + description: > + This type provides input information related to + security policy for certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + maxValidityPeriod: + description: Allowed max validity period for certificates. + type: number + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: number + delegationSupportedCertificateManagements: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + cmfInfo: + description: > + This type provides input information related to CMF + for certificate management. + type: object + required: + - id + - endPoint + - supportedProtocol + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + endPoint: + description: End point of CMF instance. + type: object + properties: + 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 + link: + description: > + This type represents a link to a resource + using an absolute URI. + type: object + required: + - href + properties: + href: + description: > + String formatted according to IETF RFC + 3986. + type: string + supportedProtocol: + description: Supported protocols by CMF instance. + type: array + items: + description: Supported protocol by CMF instance. + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + certificateChain: + description: Certificate chain that this CMF provides. + type: array + items: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + certificateContents: + description: > + Information for contents of issued certificates. The + information contained in this attribute may be updated + over time during the VNF LCM, e.g., certificate(s) + renewal. + type: array + items: + description: > + This type provides input information related to + certificate content. + + NOTE: The CertificateDesc data type is defined in clause + 7.1.19.2 of ETSI GS NFV IFA 011 [10]. + type: object + required: + - id + - certificateDescId + - certificateType + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + certificateDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + certificateType: + description: Type of this certificate. + type: string + enum: + - VNFCI_CERT + - VNFOAM_CERT + supportedCertificateManagements: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + version: + description: | + A version. + type: string + serialNumber: + description: Serial number of this certificate. + type: integer + signatureAlgorithm: + description: Algorithm of this certificate's signature. + type: string + issuer: + description: Issuer of this certificate. + type: string + notBefore: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + notAfter: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + subject: + description: Subject of this certificate. + type: string + publicKeyAlgorithm: + description: Algorithm of this certificate's public key. + type: string + publicKey: + description: Public key of this certificate. + type: string + certificateExtensions: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + instantiationState: + description: > + The instantiation state of the VNF. Permitted values: - + NOT_INSTANTIATED: The VNF instance is terminated or not + instantiated. - INSTANTIATED: The VNF instance is + instantiated. + type: string + enum: + - NOT_INSTANTIATED + - INSTANTIATED + instantiatedVnfInfo: + description: > + Information specific to an instantiated VNF instance. This + attribute shall be present if the instantiateState attribute + value is INSTANTIATED. + type: object + required: + - flavourId + - vnfState + properties: + flavourId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfState: + description: > + STARTED: The VNF instance is up and running. STOPPED: The + VNF instance has been shut down. + type: string + enum: + - STARTED + - STOPPED + vnfPowerState: + description: > + This type represents information about the power state of + a VNF instance. + type: object + required: + - powerProfileId + - name + properties: + powerProfileId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + name: + description: | + Name of the power profile as provided in the VNFD. + type: string + powerConsumptionInfo: + description: > + This type represents information about estimated power + consumption of the resources associated with the power + profile, as provided in the VNFD. + type: object + required: + - minPowerConsumption + - maxPowerConsumption + - averagePowerConsumption + properties: + minPowerConsumption: + description: > + Minimum power consumption of this power profile. + Unit is KW/h. + type: integer + maxPowerConsumption: + description: > + Maximum power consumption of this power profile. + Unit is KW/h. + type: integer + averagePowerConsumption: + description: > + Average power consumption of this power profile. + Unit is KW/h. + type: integer + scaleStatus: + description: > + Scale status of the VNF, one entry per aspect. Represents + for every scaling aspect how "big" the VNF has been + scaled w.r.t. that aspect. + + This attribute shall be present if the VNF supports + scaling. See clause B.2 for an explanation of VNF scaling. + + For an aspect that has not been deployed because the + related deployableModule has not been selected, it + indicates the scale level that has been requested in the + instantiation or in a scaling operation, or, if none has + been requested in any of them, the scale level applicable + to the aspect based on the default instantiation level. + See note 8. + type: array + items: + description: > + This type represents the scale level of a VNF instance + related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being globally + unique. + type: string + maxScaleLevels: + description: > + Maximum allowed scale levels of the VNF, one entry per + aspect. This attribute shall be present if the VNF + supports scaling. + type: array + items: + description: > + This type represents the scale level of a VNF instance + related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being globally + unique. + type: string + selectedDeployableModule: + description: > + References a currently selected deployable module, as + defined in the VNFD, that has already completed the + instantiation of its VNFCs. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + resourceCapacityDefinition: + description: > + Shows current values of VDU attributes related to resource + capacity, if different to the default values from the + VNFD, as indicated in the (one or more) request(s) of all + completed VNF LCM operation(s) that contain this + attribute. If an attribute value has been modified + multiple times, only the last value is shown. The values + indicated in this attribute are applicable to all VNFC + instances based on the VDU to which the + resourceCapacityDefinition is related. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes. + + * NOTE: Resource definitions not related to a VDU are + not considered in this version of the present document. + type: object + required: + - type + properties: + tag: + description: > + Tag assigned by the issuer of a VNF LCM operation + request that contains this data type with values to + be applied to a VDU. It is used for tracking + purposes. + + The tag is preserved in the run time record as long + as at least one value of the capacity related + attributes associated with that tag is still valid, + i.e., it has not been modified by a later VNF LCM + operation request. + + At most one tag can be included when the data type + is used in a VNF LCM operation request. + + When the data type is used in the VnfInstance data + type it may contain multiple tags, namely those + provided in VNF LCM requests, if at least one of the + values provided in that request associated to that + tag is still applicable in the VNFCs created from + this VDU, i.e., it has not been modified by a later + request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: | + Type of the resource definition referenced. + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + osContainerDescData: + description: > + Indicates values for resource capacity related + attributes in an OsContainerDesc. It shall be + present when the attribute 'type' indicates + OSCONTAINER and absent otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of an OsContainer resource. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for the + container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for the + container expressed in the same units as + specified in the + requested_memory_resources_valid_values + property in VNFD (clause 6.8.12 in ETSI GS + NFV-SOL 001 [14]) for this container + descriptor. See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources of the + type indicated in the key. The key is a string + that identifies an extended resource indicated + in the extended_resource_requests property in + the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 + [14]) for this container descriptor. The value + is an integer that indicates the required + amount for a particular extended resource. See + note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container can + maximally use in milli-CPU. See note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required for all + the hugepages of the size indicated in the + key. The key is a string and corresponds to + one of the values of the hugepage sizes + indicated in the huge_pages_resources property + in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL + 001 [14]) for this container descriptor. The + value is a number that indicates the required + total size expressed in the same units as in + the huge_pages_resource property in the VNFD + (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) + that indicates the valid values for required + total size for the particular hugepage size. + See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or + OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores + are requested to be allocated to logical + CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states of + virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual compute + resource of a VM. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required for all + the hugepages of the size indicated in the key. + The key is a string and corresponds to one of + the values of the hugepage sizes indicated in + the huge_pages_requirements property in the VNFD + (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for + this virtual compute descriptor. The value is a + numberthat indicates the required total size + expressed in the same units as in the + huge_pages_requirements property in the VNFD + (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) + that indicates the valid vaues for required + total size for the particular hugepage size. See + note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores + are requested to be allocated to logical CPU + cores according to the + cpuOperationalPowerStates attribute. In case + of "DYNAMIC", the CPU power states of + virtual CPU cores can be allocated to + logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size related + attribute in an VirtualStorageDesc. It shall be + present when the attribute 'type' indicates STORAGE + and absent otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual storage + resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + extCpInfo: + description: > + Information about the external CPs exposed by the VNF + instance. When trunking is enabled, the list of entries + includes both, external CPs corresponding to parent ports + of a trunk, and external CPs associated to sub-ports of a + trunk.See note 7. + type: array + items: + description: "This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n" + type: object + required: + - id + - cpdId + - cpConfigId + - cpProtocolInfo + oneOf: + - required: + - associatedVnfcCpId + - required: + - associatedVipCpId + - required: + - associatedVnfVirtualLinkId + properties: + id: + 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 + cpConfigId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + cpProtocolInfo: + description: | + Network protocol information for this CP. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and protocol(s) + associated to the network address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned to a + virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and + been associated to the CP. + type: array + items: + type: string + extLinkPortId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + associatedVnfcCpId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + associatedVipCpId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + associatedVirtualCpId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + associatedVnfVirtualLinkId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceInfo” structure + that provides the specification of the interface to + attach the connection point to a secondary container + cluster network. See notes 3 and 4. + + It shall be present if the external CP is associated + to a VNFC realized by one or a set of OS containers + and is connected to a secondary container cluster + network. It shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" structure + that provides the information of the certificate(s) + that this VNF CP instance uses. Shall be present + when using in delegation-mode. Otherwise shall not + be present. This attribute shall be supported when + delegation mode in certificate management is + applicable. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + cpSecurityGroupInfo: + description: > + This type provides the list of active security group + rules applied to an external CP instance. The type + identifies which "SecurityGroupRule" specified in + the VNFD are activated and the values of its + attributes. + type: object + required: + - securityGroupRuleId + - etherType + - protocol + - portRangeMin + - portRangeMax + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + description: + description: > + Human readable description of the security group + rule. + type: string + etherType: + description: > + Indicates the protocol carried over the Ethernet + layer. Permitted values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + protocol: + description: > + Indicates the protocol carried over the IP + layer. Permitted values: any protocol defined in + the IANA protocol registry (refer to clause + 9.10.1.2 ofd ETSI GS NFV-SOL 001 for further + information). + type: string + portRangeMin: + description: > + Value for the minimum port number in the range + that is matched by the security group rule. + type: integer + portRangeMax: + description: > + Value for the maximum port number in the range + that is matched by the security group rule. + type: integer + vipCpInfo: + description: > + VIP CPs that are part of the VNF instance. Shall be + present when that particular VIP CP of the VNFC instance + is associated to an external CP of the VNF instance. May + be present otherwise. + type: array + minItems: 1 + items: + description: "This type provides information related to virtual IP (VIP) CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n" + type: object + required: + - cpInstanceId + - cpdId + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There shall be one + cpProtocolInfo for layer 3. There may be one + cpProtocolInfo for layer 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and protocol(s) + associated to the network address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned to a + virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and + been associated to the CP. + type: array + items: + type: string + associatedVnfcCpIds: + description: > + Identifiers of the VnfcCps that share the virtual IP + address allocated to the VIP CP instance. See note. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + virtualCpInfo: + description: > + Virtual CPs that are part of the VNF instance. Shall be + present when a particular Virtual CP is associated to an + external CP of the VNF instance. May be present otherwise. + type: array + items: + description: > + This type provides information related to a virtual CP + instance of a VNF. + + NOTE 1: A consumer of the VNF LCM interface can learn + the actual VNFC instances implementing the service + accessible via the virtual CP instance by querying the "vnfcResourceInfo" from the "InstantiatedVnfInfo" + and filtering by corresponding "vduIds" values. + NOTE 2: The information can be omitted because it is + already available as part of the external CP information + in the + VnfExtCpInfo structure. + type: object + required: + - cpInstanceId + - cpdId + - resourceHandle + - vduIds + properties: + cpInstanceId: + 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 + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There shall be one + cpProtocolInfo for each layer protocol supported. + This attribute may be omitted if the virtual CP is + exposed as an external CP. See note 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and protocol(s) + associated to the network address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned to a + virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and + been associated to the CP. + type: array + items: + type: string + vduIds: + description: > + Reference to the VDU(s) which implement the service + accessible via the virtual CP instance. See note 1. + type: array + minItems: 1 + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + additionalServiceInfo: + description: > + Additional service identification information of the + virtual CP instance. + type: array + items: + description: > + This type provides additional service information + of the virtual CP instance used to expose + properties of the virtual CP to NFV-MANO. + + NOTE: This attribute shall only be present if + additional information is needed to identify the + service + termination within the VNF, such as for example a URL path information in an HTTP request required + to allow a single virtual CP IP address to be used for several HTTP based services that use the + same port number. + type: object + required: + - portInfo + properties: + portInfo: + description: > + Service port numbers exposed by the virtual CP + instance. + minItems: 1 + type: array + items: + description: > + This type describes the service identifying + port properties exposed by the virtual CP + instance. + type: object + required: + - name + - port + - portConfigurable + properties: + name: + description: > + The name of the port exposed by the + virtual CP instance. + type: string + protocol: + description: > + The L4 protocol for this port exposed by + the virtual CP instance. + + Permitted values: - TCP - UDP - SCTP + type: string + enum: + - TCP + - UDP + - SCTP + port: + description: > + The L4 port number exposed by the + virtual CP instance. + type: integer + portConfigurable: + description: > + The Boolean is a data type having two + values (true and false). + type: boolean + serviceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + extVirtualLinkInfo: + description: > + Information about the external VLs the VNF instance is + connected to. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. Information about + the resource is available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource provider. + See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available from + the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be present + if the resource is managed by a CISM and + it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the current CP + configuration information for the connection of + external CPs to the external virtual link. See + note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be + configured on the CP instances created from + the respective CPD. + + The key of the map which identifies the + individual VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. + + The entries shall be applied by the VNFM + according to the rules of JSON Merge Patch + (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. + In case of deleting an external CP, the list + of instances to be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided + link port, or a network attachment + definition resource of secondary container + cluster network, or network address + information per instance of an external + connection point. In the case of VM-based + deployment of the VNFC exposing the external + CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of + the VNFC exposing the external CP, the VNFM + shall use the network attachment definition + resource of secondary container cluster + network when connecting the CP to the + external VL. + + * NOTE 1: The following conditions apply to + the attributes "linkPortId" and + "cpProtocolData" for an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to + the attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more + than one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of + being globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create + a dedicated link port for the external + CP. If set to True, the VNFM shall + create a link port. If set to False, the + VNFM shall not create a link port. This + attribute is only applicable for + external CP instances without a floating + IP address that expose a VIP CP instance + for which a dedicated IP address is + allocated. It shall be present in that + case and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceData” structure that + provides the specification of the + interface to attach the external CP to a + secondary container cluster network. It + is only applicable if the external CP is + connected or to be connected to a + secondary container cluster network. It + shall not be present if the external CP + is related to a virtual network not + categorized as secondary container + cluster network. See notes 2, 3 and 4. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects + the CP to a VL and the domain names for + the external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security + groups. The parameters identify which + "SecurityGroupRule" specified in the + VNFD is activated/deactivated and for an + activated security group rule the values + of attributes defined in the VNFD that + can be overriden such as "portRangeMin" + and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extNetAttDefResource: + description: > + Network attachment definition resources that provide + the specification of the interface to attach + connection points to this VL. + type: array + items: + description: > + This type contains information related to a + network attachment definition resource that + provides the specification of the interface used + to connect one or multiple connection points to a + secondary container cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of being + globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. Information about + the resource is available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource provider. + See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available from + the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be present + if the resource is managed by a CISM and + it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated to + this network attachment definition resource. + Shall be present when the network attachment + definition resource is used for external + connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to this + network attachment definition resource. May be + present when the network attachment + definition resource is used for internal + connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and been + associated to the CP. + type: array + items: + type: string + extManagedVirtualLinkInfo: + description: > + Information about the externally-managed internal VLs of + the VNF instance. See notes 5 and 6. + type: array + items: + description: > + This type provides information about an + externally-managed virtual link. Note: Both + "vnfLinkPort" and "vnfNetAttDefResource" attributes can + be present in an "ExtManagedVirtualLinkInfo" to + indicate that a single internal virtual link is providing connectivity for both VM-based and container-based + VNFCs. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + vnfLinkPorts: + description: | + Link ports of this VL. See note. + type: array + items: + description: > + This type represents a link port of an internal VL + of a VNF. + + NOTE 1: Either cpInstanceId with cpInstanceType + set to "EXT_CP" or any combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides + examples for configurations where both + vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is scoped + by the value of "vimConnectionId" in the + "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. Information about + the resource is available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource provider. + See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available from + the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be present + if the resource is managed by a CISM and + it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vnfNetAttDefResource: + description: > + Network attachment definition resources that provide + the specification of the interface to attach + connection points to this VL. See note. + type: array + items: + description: > + This type contains information related to a + network attachment definition resource that + provides the specification of the interface used + to connect one or multiple connection points to a + secondary container cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of being + globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. Information about + the resource is available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource provider. + See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available from + the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be present + if the resource is managed by a CISM and + it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated to + this network attachment definition resource. + Shall be present when the network attachment + definition resource is used for external + connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to this + network attachment definition resource. May be + present when the network attachment + definition resource is used for internal + connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + extManagedMultisiteVirtualLinkId: + description: > + An identifier with the intention of being globally + unique. + type: string + routingResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + monitoringParameters: + description: | + Active monitoring parameters. + type: array + items: + description: > + This type represents a monitoring parameter that is + tracked by the VNFM, + type: object + required: + - id + - performanceMetric + properties: + id: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + name: + description: > + Human readable name of the monitoring parameter, as + defined in the VNFD. + type: string + performanceMetric: + description: > + Performance metric that is monitored. This attribute + shall contain the related "Measurement Name" value + as defined in clause 7.2 of ETSI GS NFV-IFA 027. + type: string + localizationLanguage: + description: > + Information about localization language of the VNF + (includes e.g. strings in the VNFD). The localization + languages supported by a VNF can be declared in the VNFD, + and localization language selection can take place at + instantiation time. The value shall comply with the format + defined in IETF RFC 5646. + type: string + vnfcResourceInfo: + description: > + Information about the virtualised compute and storage + resources used by the VNFCs of the VNF instance. + type: array + items: + description: "This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure of\n information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n a) For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n b) For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\nNOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on \n TOSCA specifications.\nNOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an \n internal VL that exposes an external CP. A VNFC CP is \"exposed as\" an external \n CP if it is connected directly to an external VL.\nNOTE 3:\tThe information can be omitted because it is already available as part of the \n external CP information.\nNOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\"\n structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVnfc\" structure in the VNF LCM operation occurrence notifications\n or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\nNOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment\n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. \nNOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n" + type: object + required: + - id + - vduId + - computeResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + storageResourceIds: + description: > + References to the VirtualStorage resources or + references to Storage MCIOs. The value refers to a + VirtualStorageResourceInfo item in the VnfInstance. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfcCpInfo: + description: > + CPs of the VNFC instance. Shall be present when that + particular CP of the VNFC instance is exposed as an + external CP of the VNF instance or is connected to + an external CP of the VNF instance. See note 2. May + be present otherwise. See note 7. + type: array + items: + type: object + required: + - id + - cpdId + properties: + id: + 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 + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + cpProtocolInfo: + description: > + Network protocol information for this CP. May + be omitted if the VNFC CP is exposed as an + external CP. See note 3. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + parentCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceInfo” + structure that provides the specification of + the interface to attach the connection point + to a secondary container cluster network. See + notes 5 and 6. It shall be present if the + internal CP is associated to a VNFC realized + by one or a set of OS containers and is + connected to a secondary container cluster + network. It shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of the + certificate(s) that this VNFC CP instance + uses. Shall be present when using in + delegation-mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate management + is applicable + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" structure + that provides the information of the certificate(s) + that this VNFC instance uses. Shall be present when + using in delegation-mode. Otherwise shall not be + present. This attribute shall be supported when + delegation mode in certificate management is + applicable. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfVirtualLinkResourceInfo: + description: > + Information about the virtualised network resources used + by the VLs of the VNF instance. See note 6. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used by an + internal VL instance in a VNF instance. + + Note: If only the value or the presence of this + attribute is changed in the "VnfVirtualLinkResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires including + a related "AffectedVirtualLink" structure in the VNF LCM operation occurrence notifications or the + "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + reservationId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfLinkPorts: + description: > + Links ports of this VL. Shall be present when the + linkPort is used for external connectivity by the + VNF (refer to VnfLinkPortInfo). May be present + otherwise. + type: array + items: + description: > + This type represents a link port of an internal VL + of a VNF. + + NOTE 1: Either cpInstanceId with cpInstanceType + set to "EXT_CP" or any combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides + examples for configurations where both + vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is scoped + by the value of "vimConnectionId" in the + "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. Information about + the resource is available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource provider. + See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available from + the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be present + if the resource is managed by a CISM and + it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + virtualStorageResourceInfo: + description: > + Information on the virtualised storage resource(s) used as + storage for the VNF instance. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. + + Note: If only the value or the presence of this + attribute is changed in the "VirtualStorageResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires + including a related "AffectedVirtualStorage" structure in the VNF LCM operation occurrence + notifications or the "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - virtualStorageDescId + - storageResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + reservationId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + mcioInfo: + description: > + Information on the MCIO(s) representing VNFC instance(s) + realized by one or a set of OS containers and created from + the same VDU for the VNF instance. + type: array + items: + description: > + This type provides information about an MCIO + representing the set of VNFC instances realized by one + or a set of OS containers which have been created based + on the same VDU. Within the CISM, an MCIO controller + monitors the actual state of an MCIO representing the + set of VNFC instances realized by one or a set of OS + containers and compare it to the desired state For an + MCIO related to a VDU that has the attribute + isNumOfInstancesClusterBased set to FALSE the desired + state is specified in the respective declarative + descriptor. For an MCIO related to a VDU that has the + attribute isNumOfInstancesClusterBased set to TRUE, the + desired state is determined by the number of CIS-nodes + in the cluster that fulfil the VDU requirements.as + specified in the respective declarative descriptor. It + triggers actions toward the CIS to align the actual to + the desired state. Monitoring the actual state includes + monitoring the number of MCIO instances available at + any specific point in time. In addition, an MCIO + controller maintains properties and runtime information + on the MCIO instances which have been created based on + the same VDU. The McioInfo data structure provides the + runtime information on the MCIOs obtained from the MCIO + controller. + + NOTE: There are different types of MCIOs. The set of + VNFC instances based on the same VDU is represented + by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type + of MCIO, e.g. a POD. + + Runtime information of the set of OS containers + realizing an individual VNFC instance is not part of + the McioInfo data structure; such runtime information + is provided in the ResourceHandle data structure + referenced from the VnfcResourceInfo. The McioInfo does + not provide runtime information of a constituent VNFC + instance created based on a specific VDU. + + NOTE 1: The type of MCIO as specified in the declarative + descriptor of the MCIO, and that can be read from + the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the + “kind” property of the declarative descriptor. + NOTE 2: If the attribute additionalInfo is present, it + may contain runtime information on the actual and + desired state of the MCIO(s). + NOTE 3: When the container infrastructure service is a + Kubernetes® instance, the mcioId is the combined + values from the kind and name fields of the Kubernetes resource object, separated by a slash. + Example: "Deployment/abcd". + NOTE 4: When the container infrastructure service is a + Kubernetes® instance, the mcioName is the name + field of the resource object. + type: object + required: + - mcioId + - mcioName + - mcioNamespace + - vduId + - cismId + - mcioType + - desiredInstances + - availableInstances + properties: + mcioId: + description: > + An identifier with the intention of being globally + unique. + type: string + mcioName: + description: | + Human readable name of this MCIO. See note 4. + type: string + mcioNamespace: + description: | + Namespace of this MCIO. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cismId: + description: > + An identifier with the intention of being globally + unique. + type: string + mcioType: + description: > + The type of MCIO. Specific values, their semantics + and associated MCIO types are defined in clause + 5.5.4.9. Additional values are also permitted. See + note 1. + type: string + enum: + - Deployment + - Statefulset + - DaemonSet + desiredInstances: + description: | + Number of desired MCIO instances. + type: integer + availableInstances: + description: | + Number of available MCIO instances. + type: integer + additionalInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" structure + that provides the information of the certificate(s) + that this MCIO instance uses. Shall be present when + using in delegation mode. Otherwise shall not be + present. This attribute shall be supported when + delegation mode in certificate management is + applicable. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfPaasServiceInfo: + description: > + Information on the PaaS Services assigned and used by the + VNF instance. + type: array + items: + description: > + This type provides input information about a PaaS + Service that is used by a VNF instance. The + PaasServiceInfo is comprised of various sets of + information. Some information comes from the VNFD, other + information comes from the PaaS Service assets provided + by the NFVO to the VNFM, and other information is + provided at runtime information about the usage of the + PaaS Service. + type: object + required: + - id + - paasServiceId + - paasServiceType + - paasServiceRequestId + - paasServiceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceType: + description: >- + The type of PaaS Service. The value of this + attribute is expected to be matched against values + of the registered PaaS Services in the PSR. + type: string + paasServiceVersion: + description: | + A version. + type: string + paasServiceRequestId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + paasServiceHandle: + description: > + This type provides information enabling the access + and use of the PaaS Service by the VNF instance. The + type and format of the handle depends on the form + that the PaaS Service is formed. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + additionalInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + indicators: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + instantiate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + terminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + heal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + operate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + createSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + revertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeCurrentVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperationLinks: + description: > + Links to the most recent LCM operation occurrences related to + this resource. See note 9. + type: object + properties: + recentVnfLcmOperation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmInstantiation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmTerminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmHeal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmModifyInfo: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmCreateSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmRevertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmSelectDplMods: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + VNFInstances.Post.422: + description: | + 422 Unprocessable Content + + Shall be returned upon the following error: The content + type of the message content is supported and the message + content of a request contains syntactically correct data + but the data cannot be processed. + The general cause for this error and its handling is + specified in clause 6.4 of ETSI GS NFV-SOL 013 [8], + including rules for the presence of the response body. + Specifically in case of this resource, the response + code 422 shall also be returned if the VNF package + referenced by the "vnfdId" attribute in the + "CreateVnfRequest" structure is not in the "ENABLED" + state or does not exist. In this case, the "detail" + attribute in the "ProblemDetails" structure shall convey + more information about the error + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + VNFInstances.Get.200: + description: > + 200 OK + + + Shall be returned when information about zero or more VNF instances has + been queried successfully. + + The response body shall contain in an array the representations of zero + or more VNF instances, + + as defined in clause 5.5.2.2. + + If the "filter" URI parameter or one of the "all_fields", "fields" (if + supported), "exclude_fields" + + (if supported) or "exclude_default" URI parameters was supplied in the + request, the data in the response + + body shall have been transformed according to the rules specified in + clauses 5.2.2 and 5.3.2 of + + ETSI GS NFV-SOL 013, respectively. + + If the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 + of ETSI GS NFV-SOL 013 + + for this resource, inclusion of the Link HTTP header in this response + shall follow the provisions + + in clause 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: "This type represents a VNF instance.\nNOTE:\tClause B.3.2 provides examples illustrating the relationship among the different run-time \n information elements (CP, VL and link ports) used to represent the connectivity of a VNF.\n\nNOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist between \n the previous and the newly referred VNF package, i.e. when the new VNFD is changed with \n respect to the previous VNFD in other aspects than merely referencing to other VNF software \n images. In order to avoid misalignment of the VnfInstance with the current VNF's on-boarded \n VNF Package, the values of attributes in the VnfInstance that have corresponding attributes \n in the VNFD shall be kept in sync with the values in the VNFD.\nNOTE 2:\tETSI GS NFV-SOL 001 [14] specifies the structure and format of the VNFD based on TOSCA specifications. NOTE 3:\tVNF configurable properties are sometimes also referred to as configuration parameters applicable \n to a VNF. Some of these are set prior to instantiation and cannot be modified if the VNF is instantiated, \n some are set prior to instantiation (are part of initial configuration) and can be modified later, \n and others can be set only after instantiation. The applicability of certain configuration may \n depend on the VNF and the required operation of the VNF at a certain point in time.\nNOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes \n of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared in the VNFD with a defined \n initial value. The defined initial values can be declared in the VNFD, and/or, in case of \"metadata\", \n obtained from the \"CreateVnfRequest\" structure. Child attributes of \"vnfConfigurableProperties\", \n \"metadata\" and \"extensions\" that have no defined initial value shall not be created, in order to be \n consistent with the semantics of the JSON Merge Patch method (see IETF RFC 7396) that interprets null \n values as deletion request.\nNOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a \n multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same \n VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed \n multi-site VL instance (refer to clause 5.5.3.3).\nNOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity, they shall \n not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\nNOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing \n the trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\nNOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the \n VNF LCM operation explicitly indicates the scale level for the aspect.\nNOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n" + type: object + required: + - id + - vnfdId + - vnfProvider + - vnfProductName + - vnfSoftwareVersion + - vnfdVersion + - instantiationState + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfInstanceName: + description: > + Name of the VNF instance. This attribute can be modified + with the PATCH method. + type: string + vnfInstanceDescription: + description: > + Human-readable description of the VNF instance. This + attribute can be modified with the PATCH method. + type: string + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfProvider: + description: > + Provider of the VNF and the VNFD. The value is copied from + the VNFD. + type: string + vnfProductName: + description: > + Name to identify the VNF Product. The value is copied from + the VNFD. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + vimConnectionInfo: + description: > + Information about VIM or CISM connections to be used for + managing the resources for the VNF instance. The keys of the + map, each of which identifies information about a particular + VIM connection, are managed by the NFVO and referenced from + other data structures via the "vimConnectionId" attribute. + This attribute shall only be supported and present if - the + resources of at least of the VNFCs are managed by a VIM and + VNF-related resource management in direct mode is + applicable. - the resources of at least of the VNFCs are + managed by a CISM. This attribute can be modified with the + PATCH method. If VIM connection information is provisioned + to the VNFM by means outside the scope of the present + document, the information in the "vimConnectionInfo" + attribute provides necessary information for binding the + VnfInstance representing the "Individual VNF instance" to + the applicable VIM connection information used to perform + resource management for the VNF instance. See also the + definition of the "VimConnectionInfo" in clause 4.4.1.6. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines + the structure of the "interfaceInfo" and "accessInfo" + attributes, based on the type of the VIM., CISM, CIR + or MCIOP repository. The set of permitted values is + expected to change over time as new types or versions + of VIMs become available. The ETSI NFV registry of + VIM-related information provides access to information + about VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The structure of + the registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + cirConnectionInfo: + description: > + Information about the CIR connection for managing OS + container images for the VNF instance. Shall be present when + all or part of the VNF is realized by a set of OS containers + and shall be absent otherwise. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines + the structure of the "interfaceInfo" and "accessInfo" + attributes, based on the type of the VIM., CISM, CIR + or MCIOP repository. The set of permitted values is + expected to change over time as new types or versions + of VIMs become available. The ETSI NFV registry of + VIM-related information provides access to information + about VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The structure of + the registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + mciopRepositoryInfo: + description: > + Information about the MCIOP repository for the VNF instance. + Shall be present when all or part of the VNF is realized by + a set of OS containers and shall be absent otherwise. See + note 1. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines + the structure of the "interfaceInfo" and "accessInfo" + attributes, based on the type of the VIM., CISM, CIR + or MCIOP repository. The set of permitted values is + expected to change over time as new types or versions + of VIMs become available. The ETSI NFV registry of + VIM-related information provides access to information + about VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The structure of + the registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + certificateInfo: + description: > + This type provides input information related to certificate + and certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + certificateConfigurationInfo: + description: > + This type provides input information related to + certificate management. + type: object + required: + - securityPolicy + properties: + certificateBaseProfile: + description: Information for certificate profile. + type: array + items: + description: > + NOTE: At least one overriding attributes shall be + present, otherwise shall be absent. + + This type provides input information to override + certificate base profile for certificate + management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + issuer: + description: Issuer of certificates. See note. + type: string + issuerUniqueIdentifier: + description: > + An identifier with the intention of being + globally unique. + type: string + subject: + description: > + This type provides input information related + to the subject of the certificate. + + NOTE: At least one overriding attributes shall + be present, otherwise shall be absent. + type: object + properties: + commonName: + description: > + Information of the certification target + subject FQDN. Can be set empty when this + certificate is used for encrypted + communication using IP address. See note. + type: string + organization: + description: >- + Information of the certification target + subject Organization. See note. + type: string + country: + description: >- + Information of the certification target + subject Country. See note. + type: string + state: + description: >- + Information of the certification target + subject State. See note. + type: string + locality: + description: >- + Information of the certification target + subject Locality. See note. + type: string + emailAddress: + description: >- + Information of the certification contact + email address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of being + globally unique. + type: string + basicConstraints: + description: Basic constraints of certificates. See note. + type: string + issuerAltName: + description: >- + Alternative name of issuer of certificates in + this NS. See note. + type: array + items: + type: string + subjectAltName: + description: > + Alternative name of subject of certificates. + Shall be present when this certificate is used + for encrypted communication using IP address + and subjectAltName attribute of + CertificateBaseProfile in CertificateDesc of + VNFD is empty (see ETSI GS NFV-IFA 011 [14], + clause 7.1.19.4). See note. + type: array + items: + type: string + nameConstraints: + description: Name constraints of certificates. See note. + type: array + items: + type: string + securityPolicy: + description: >- + Information for security policy to be satisfied for + certificate. + type: array + items: + description: > + This type provides input information related to + security policy for certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + maxValidityPeriod: + description: Allowed max validity period for certificates. + type: number + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: number + delegationSupportedCertificateManagements: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + cmfInfo: + description: > + This type provides input information related to CMF + for certificate management. + type: object + required: + - id + - endPoint + - supportedProtocol + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + endPoint: + description: End point of CMF instance. + type: object + properties: + 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 + link: + description: > + This type represents a link to a resource + using an absolute URI. + type: object + required: + - href + properties: + href: + description: > + String formatted according to IETF RFC + 3986. + type: string + supportedProtocol: + description: Supported protocols by CMF instance. + type: array + items: + description: Supported protocol by CMF instance. + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + certificateChain: + description: Certificate chain that this CMF provides. + type: array + items: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + certificateContents: + description: > + Information for contents of issued certificates. The + information contained in this attribute may be updated + over time during the VNF LCM, e.g., certificate(s) + renewal. + type: array + items: + description: > + This type provides input information related to + certificate content. + + NOTE: The CertificateDesc data type is defined in + clause 7.1.19.2 of ETSI GS NFV IFA 011 [10]. + type: object + required: + - id + - certificateDescId + - certificateType + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + certificateDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + certificateType: + description: Type of this certificate. + type: string + enum: + - VNFCI_CERT + - VNFOAM_CERT + supportedCertificateManagements: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + version: + description: | + A version. + type: string + serialNumber: + description: Serial number of this certificate. + type: integer + signatureAlgorithm: + description: Algorithm of this certificate's signature. + type: string + issuer: + description: Issuer of this certificate. + type: string + notBefore: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + notAfter: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + subject: + description: Subject of this certificate. + type: string + publicKeyAlgorithm: + description: Algorithm of this certificate's public key. + type: string + publicKey: + description: Public key of this certificate. + type: string + certificateExtensions: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + instantiationState: + description: > + The instantiation state of the VNF. Permitted values: - + NOT_INSTANTIATED: The VNF instance is terminated or not + instantiated. - INSTANTIATED: The VNF instance is + instantiated. + type: string + enum: + - NOT_INSTANTIATED + - INSTANTIATED + instantiatedVnfInfo: + description: > + Information specific to an instantiated VNF instance. This + attribute shall be present if the instantiateState attribute + value is INSTANTIATED. + type: object + required: + - flavourId + - vnfState + properties: + flavourId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfState: + description: > + STARTED: The VNF instance is up and running. STOPPED: + The VNF instance has been shut down. + type: string + enum: + - STARTED + - STOPPED + vnfPowerState: + description: > + This type represents information about the power state + of a VNF instance. + type: object + required: + - powerProfileId + - name + properties: + powerProfileId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + name: + description: | + Name of the power profile as provided in the VNFD. + type: string + powerConsumptionInfo: + description: > + This type represents information about estimated + power consumption of the resources associated with + the power profile, as provided in the VNFD. + type: object + required: + - minPowerConsumption + - maxPowerConsumption + - averagePowerConsumption + properties: + minPowerConsumption: + description: > + Minimum power consumption of this power profile. + Unit is KW/h. + type: integer + maxPowerConsumption: + description: > + Maximum power consumption of this power profile. + Unit is KW/h. + type: integer + averagePowerConsumption: + description: > + Average power consumption of this power profile. + Unit is KW/h. + type: integer + scaleStatus: + description: > + Scale status of the VNF, one entry per aspect. + Represents for every scaling aspect how "big" the VNF + has been scaled w.r.t. that aspect. + + This attribute shall be present if the VNF supports + scaling. See clause B.2 for an explanation of VNF + scaling. + + For an aspect that has not been deployed because the + related deployableModule has not been selected, it + indicates the scale level that has been requested in the + instantiation or in a scaling operation, or, if none + has been requested in any of them, the scale level + applicable to the aspect based on the default + instantiation level. See note 8. + type: array + items: + description: > + This type represents the scale level of a VNF instance + related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being globally + unique. + type: string + maxScaleLevels: + description: > + Maximum allowed scale levels of the VNF, one entry per + aspect. This attribute shall be present if the VNF + supports scaling. + type: array + items: + description: > + This type represents the scale level of a VNF instance + related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being globally + unique. + type: string + selectedDeployableModule: + description: > + References a currently selected deployable module, as + defined in the VNFD, that has already completed the + instantiation of its VNFCs. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + resourceCapacityDefinition: + description: > + Shows current values of VDU attributes related to + resource capacity, if different to the default values + from the VNFD, as indicated in the (one or more) + request(s) of all completed VNF LCM operation(s) that + contain this attribute. If an attribute value has been + modified multiple times, only the last value is shown. + The values indicated in this attribute are applicable + to all VNFC instances based on the VDU to which the + resourceCapacityDefinition is related. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes. + + * NOTE: Resource definitions not related to a VDU are + not considered in this version of the present + document. + type: object + required: + - type + properties: + tag: + description: > + Tag assigned by the issuer of a VNF LCM operation + request that contains this data type with values + to be applied to a VDU. It is used for tracking + purposes. + + The tag is preserved in the run time record as + long as at least one value of the capacity + related attributes associated with that tag is + still valid, i.e., it has not been modified by a + later VNF LCM operation request. + + At most one tag can be included when the data type + is used in a VNF LCM operation request. + + When the data type is used in the VnfInstance data + type it may contain multiple tags, namely those + provided in VNF LCM requests, if at least one of + the values provided in that request associated to + that tag is still applicable in the VNFCs created + from this VDU, i.e., it has not been modified by a + later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: | + Type of the resource definition referenced. + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + osContainerDescData: + description: > + Indicates values for resource capacity related + attributes in an OsContainerDesc. It shall be + present when the attribute 'type' indicates + OSCONTAINER and absent otherwise. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes of an + OsContainer resource. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for the + container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for the + container expressed in the same units as + specified in the + requested_memory_resources_valid_values + property in VNFD (clause 6.8.12 in ETSI GS + NFV-SOL 001 [14]) for this container + descriptor. See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources of + the type indicated in the key. The key is a + string that identifies an extended resource + indicated in the extended_resource_requests + property in the VNFD (clause 6.8.12 in ETSI + GS NFV-SOL 001 [14]) for this container + descriptor. The value is an integer that + indicates the required amount for a + particular extended resource. See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container can + maximally use in milli-CPU. See note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required for + all the hugepages of the size indicated in + the key. The key is a string and corresponds + to one of the values of the hugepage sizes + indicated in the huge_pages_resources + property in the VNFD (clause 6.8.12 in ETSI + GS NFV-SOL 001 [14]) for this container + descriptor. The value is a number that + indicates the required total size expressed + in the same units as in the + huge_pages_resource property in the VNFD + (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) + that indicates the valid values for required + total size for the particular hugepage size. + See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute + or OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU + cores are requested to be allocated to + logical CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states + of virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on + core utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual compute + resource of a VM. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required for all + the hugepages of the size indicated in the + key. The key is a string and corresponds to + one of the values of the hugepage sizes + indicated in the huge_pages_requirements + property in the VNFD (clause 6.2.7.2 in ETSI + GS NFV-SOL 001 [14]) for this virtual compute + descriptor. The value is a numberthat + indicates the required total size expressed in + the same units as in the + huge_pages_requirements property in the VNFD + (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) + that indicates the valid vaues for required + total size for the particular hugepage size. + See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or + OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores + are requested to be allocated to logical + CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states of + virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size related + attribute in an VirtualStorageDesc. It shall be + present when the attribute 'type' indicates + STORAGE and absent otherwise. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes of the virtual + storage resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + extCpInfo: + description: > + Information about the external CPs exposed by the VNF + instance. When trunking is enabled, the list of entries + includes both, external CPs corresponding to parent + ports of a trunk, and external CPs associated to + sub-ports of a trunk.See note 7. + type: array + items: + description: "This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n" + type: object + required: + - id + - cpdId + - cpConfigId + - cpProtocolInfo + oneOf: + - required: + - associatedVnfcCpId + - required: + - associatedVipCpId + - required: + - associatedVnfVirtualLinkId + properties: + id: + 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 + cpConfigId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + cpProtocolInfo: + description: | + Network protocol information for this CP. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and protocol(s) + associated to the network address + information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned to a + virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and + been associated to the CP. + type: array + items: + type: string + extLinkPortId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + associatedVnfcCpId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + associatedVipCpId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + associatedVirtualCpId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + associatedVnfVirtualLinkId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceInfo” + structure that provides the specification of the + interface to attach the connection point to a + secondary container cluster network. See notes 3 + and 4. + + It shall be present if the external CP is + associated to a VNFC realized by one or a set of + OS containers and is connected to a secondary + container cluster network. It shall not be present + otherwise. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of the + certificate(s) that this VNF CP instance uses. + Shall be present when using in delegation-mode. + Otherwise shall not be present. This attribute + shall be supported when delegation mode in + certificate management is applicable. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + cpSecurityGroupInfo: + description: > + This type provides the list of active security + group rules applied to an external CP instance. + The type identifies which "SecurityGroupRule" + specified in the VNFD are activated and the values + of its attributes. + type: object + required: + - securityGroupRuleId + - etherType + - protocol + - portRangeMin + - portRangeMax + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + description: + description: > + Human readable description of the security + group rule. + type: string + etherType: + description: > + Indicates the protocol carried over the + Ethernet layer. Permitted values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + protocol: + description: > + Indicates the protocol carried over the IP + layer. Permitted values: any protocol defined + in the IANA protocol registry (refer to clause + 9.10.1.2 ofd ETSI GS NFV-SOL 001 for further + information). + type: string + portRangeMin: + description: > + Value for the minimum port number in the range + that is matched by the security group rule. + type: integer + portRangeMax: + description: > + Value for the maximum port number in the range + that is matched by the security group rule. + type: integer + vipCpInfo: + description: > + VIP CPs that are part of the VNF instance. Shall be + present when that particular VIP CP of the VNFC instance + is associated to an external CP of the VNF instance. May + be present otherwise. + type: array + minItems: 1 + items: + description: "This type provides information related to virtual IP (VIP) CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n" + type: object + required: + - cpInstanceId + - cpdId + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There shall be + one cpProtocolInfo for layer 3. There may be one + cpProtocolInfo for layer 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and protocol(s) + associated to the network address + information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned to a + virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and + been associated to the CP. + type: array + items: + type: string + associatedVnfcCpIds: + description: > + Identifiers of the VnfcCps that share the virtual + IP address allocated to the VIP CP instance. See + note. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + virtualCpInfo: + description: > + Virtual CPs that are part of the VNF instance. Shall be + present when a particular Virtual CP is associated to an + external CP of the VNF instance. May be present + otherwise. + type: array + items: + description: > + This type provides information related to a virtual CP + instance of a VNF. + + NOTE 1: A consumer of the VNF LCM interface can learn + the actual VNFC instances implementing the service + accessible via the virtual CP instance by querying the "vnfcResourceInfo" from the "InstantiatedVnfInfo" + and filtering by corresponding "vduIds" values. + NOTE 2: The information can be omitted because it is + already available as part of the external CP + information in the + VnfExtCpInfo structure. + type: object + required: + - cpInstanceId + - cpdId + - resourceHandle + - vduIds + properties: + cpInstanceId: + 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 + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There shall be + one cpProtocolInfo for each layer protocol + supported. This attribute may be omitted if the + virtual CP is exposed as an external CP. See note + 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and protocol(s) + associated to the network address + information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned to a + virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and + been associated to the CP. + type: array + items: + type: string + vduIds: + description: > + Reference to the VDU(s) which implement the + service accessible via the virtual CP instance. + See note 1. + type: array + minItems: 1 + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + additionalServiceInfo: + description: > + Additional service identification information of + the virtual CP instance. + type: array + items: + description: > + This type provides additional service + information of the virtual CP instance used to + expose properties of the virtual CP to + NFV-MANO. + + NOTE: This attribute shall only be present if + additional information is needed to identify the + service + termination within the VNF, such as for example a URL path information in an HTTP request required + to allow a single virtual CP IP address to be used for several HTTP based services that use the + same port number. + type: object + required: + - portInfo + properties: + portInfo: + description: > + Service port numbers exposed by the virtual + CP instance. + minItems: 1 + type: array + items: + description: > + This type describes the service + identifying port properties exposed by the + virtual CP instance. + type: object + required: + - name + - port + - portConfigurable + properties: + name: + description: > + The name of the port exposed by the + virtual CP instance. + type: string + protocol: + description: > + The L4 protocol for this port exposed by + the virtual CP instance. + + Permitted values: - TCP - UDP - SCTP + type: string + enum: + - TCP + - UDP + - SCTP + port: + description: > + The L4 port number exposed by the + virtual CP instance. + type: integer + portConfigurable: + description: > + The Boolean is a data type having two + values (true and false). + type: boolean + serviceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + extVirtualLinkInfo: + description: > + Information about the external VLs the VNF instance is + connected to. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the current CP + configuration information for the connection of + external CPs to the external virtual link. See + note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be + configured on the CP instances created from + the respective CPD. + + The key of the map which identifies the + individual VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the + NFVO. + + The entries shall be applied by the VNFM + according to the rules of JSON Merge Patch + (see IETF RFC 7396). See notes 2, 3, 4, 5, + 6. In case of deleting an external CP, the + list of instances to be deleted. + type: object + additionalProperties: + description: > + This type represents an externally + provided link port, or a network + attachment definition resource of + secondary container cluster network, or + network address information per instance + of an external connection point. In the + case of VM-based deployment of the VNFC + exposing the external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment + of the VNFC exposing the external CP, the + VNFM shall use the network attachment + definition resource of secondary container + cluster network when connecting the CP to + the external VL. + + * NOTE 1: The following conditions apply + to the attributes "linkPortId" and + "cpProtocolData" for an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply + to the attributes “netAttDefResourceId” + and “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is + only applicable for specific cases where + more than one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but + not both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of + being globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create + a dedicated link port for the external + CP. If set to True, the VNFM shall + create a link port. If set to False, the + VNFM shall not create a link port. This + attribute is only applicable for + external CP instances without a floating + IP address that expose a VIP CP instance + for which a dedicated IP address is + allocated. It shall be present in that + case and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceData” structure that + provides the specification of the + interface to attach the external CP to a + secondary container cluster network. It + is only applicable if the external CP is + connected or to be connected to a + secondary container cluster network. It + shall not be present if the external CP + is related to a virtual network not + categorized as secondary container + cluster network. See notes 2, 3 and 4. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects + the CP to a VL and the domain names for + the external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security + groups. The parameters identify which + "SecurityGroupRule" specified in the + VNFD is activated/deactivated and for an + activated security group rule the values + of attributes defined in the VNFD that + can be overriden such as "portRangeMin" + and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extNetAttDefResource: + description: > + Network attachment definition resources that + provide the specification of the interface to + attach connection points to this VL. + type: array + items: + description: > + This type contains information related to a + network attachment definition resource that + provides the specification of the interface + used to connect one or multiple connection + points to a secondary container cluster + network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of being + globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated to + this network attachment definition resource. + Shall be present when the network + attachment definition resource is used for + external connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to this + network attachment definition resource. May + be present when the network attachment + definition resource is used for internal + connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and been + associated to the CP. + type: array + items: + type: string + extManagedVirtualLinkInfo: + description: > + Information about the externally-managed internal VLs of + the VNF instance. See notes 5 and 6. + type: array + items: + description: > + This type provides information about an + externally-managed virtual link. Note: Both + "vnfLinkPort" and "vnfNetAttDefResource" attributes + can be present in an "ExtManagedVirtualLinkInfo" to + indicate that a single internal virtual link is providing connectivity for both VM-based and container-based + VNFCs. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + vnfLinkPorts: + description: | + Link ports of this VL. See note. + type: array + items: + description: > + This type represents a link port of an internal + VL of a VNF. + + NOTE 1: Either cpInstanceId with cpInstanceType + set to "EXT_CP" or any combination of + cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 + provides examples for configurations where both + vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is scoped + by the value of "vimConnectionId" in the + "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vnfNetAttDefResource: + description: > + Network attachment definition resources that + provide the specification of the interface to + attach connection points to this VL. See note. + type: array + items: + description: > + This type contains information related to a + network attachment definition resource that + provides the specification of the interface + used to connect one or multiple connection + points to a secondary container cluster + network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of being + globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated to + this network attachment definition resource. + Shall be present when the network + attachment definition resource is used for + external connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to this + network attachment definition resource. May + be present when the network attachment + definition resource is used for internal + connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + extManagedMultisiteVirtualLinkId: + description: > + An identifier with the intention of being globally + unique. + type: string + routingResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + monitoringParameters: + description: | + Active monitoring parameters. + type: array + items: + description: > + This type represents a monitoring parameter that is + tracked by the VNFM, + type: object + required: + - id + - performanceMetric + properties: + id: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + name: + description: > + Human readable name of the monitoring parameter, + as defined in the VNFD. + type: string + performanceMetric: + description: > + Performance metric that is monitored. This + attribute shall contain the related "Measurement + Name" value as defined in clause 7.2 of ETSI GS + NFV-IFA 027. + type: string + localizationLanguage: + description: > + Information about localization language of the VNF + (includes e.g. strings in the VNFD). The localization + languages supported by a VNF can be declared in the + VNFD, and localization language selection can take place + at instantiation time. The value shall comply with the + format defined in IETF RFC 5646. + type: string + vnfcResourceInfo: + description: > + Information about the virtualised compute and storage + resources used by the VNFCs of the VNF instance. + type: array + items: + description: "This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure of\n information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n a) For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n b) For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\nNOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on \n TOSCA specifications.\nNOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an \n internal VL that exposes an external CP. A VNFC CP is \"exposed as\" an external \n CP if it is connected directly to an external VL.\nNOTE 3:\tThe information can be omitted because it is already available as part of the \n external CP information.\nNOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\"\n structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVnfc\" structure in the VNF LCM operation occurrence notifications\n or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\nNOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment\n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. \nNOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n" + type: object + required: + - id + - vduId + - computeResource + properties: + id: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + storageResourceIds: + description: > + References to the VirtualStorage resources or + references to Storage MCIOs. The value refers to a + VirtualStorageResourceInfo item in the + VnfInstance. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfcCpInfo: + description: > + CPs of the VNFC instance. Shall be present when + that particular CP of the VNFC instance is + exposed as an external CP of the VNF instance or + is connected to an external CP of the VNF + instance. See note 2. May be present otherwise. + See note 7. + type: array + items: + type: object + required: + - id + - cpdId + properties: + id: + 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 + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpProtocolInfo: + description: > + Network protocol information for this CP. + May be omitted if the VNFC CP is exposed as + an external CP. See note 3. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + parentCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceInfo” + structure that provides the specification of + the interface to attach the connection point + to a secondary container cluster network. + See notes 5 and 6. It shall be present if + the internal CP is associated to a VNFC + realized by one or a set of OS containers + and is connected to a secondary container + cluster network. It shall not be present + otherwise. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this VNFC CP + instance uses. Shall be present when using + in delegation-mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of the + certificate(s) that this VNFC instance uses. + Shall be present when using in delegation-mode. + Otherwise shall not be present. This attribute + shall be supported when delegation mode in + certificate management is applicable. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfVirtualLinkResourceInfo: + description: > + Information about the virtualised network resources used + by the VLs of the VNF instance. See note 6. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used by an + internal VL instance in a VNF instance. + + Note: If only the value or the presence of this + attribute is changed in the + "VnfVirtualLinkResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires including + a related "AffectedVirtualLink" structure in the VNF LCM operation occurrence notifications or the + "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + reservationId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfLinkPorts: + description: > + Links ports of this VL. Shall be present when the + linkPort is used for external connectivity by the + VNF (refer to VnfLinkPortInfo). May be present + otherwise. + type: array + items: + description: > + This type represents a link port of an internal + VL of a VNF. + + NOTE 1: Either cpInstanceId with cpInstanceType + set to "EXT_CP" or any combination of + cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 + provides examples for configurations where both + vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is scoped + by the value of "vimConnectionId" in the + "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + metadata: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + virtualStorageResourceInfo: + description: > + Information on the virtualised storage resource(s) used + as storage for the VNF instance. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. + + Note: If only the value or the presence of this + attribute is changed in the + "VirtualStorageResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires + including a related "AffectedVirtualStorage" structure in the VNF LCM operation occurrence + notifications or the "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - virtualStorageDescId + - storageResource + properties: + id: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + reservationId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + mcioInfo: + description: > + Information on the MCIO(s) representing VNFC instance(s) + realized by one or a set of OS containers and created + from the same VDU for the VNF instance. + type: array + items: + description: > + This type provides information about an MCIO + representing the set of VNFC instances realized by + one or a set of OS containers which have been created + based on the same VDU. Within the CISM, an MCIO + controller monitors the actual state of an MCIO + representing the set of VNFC instances realized by + one or a set of OS containers and compare it to the + desired state For an MCIO related to a VDU that has + the attribute isNumOfInstancesClusterBased set to + FALSE the desired state is specified in the respective + declarative descriptor. For an MCIO related to a VDU + that has the attribute isNumOfInstancesClusterBased + set to TRUE, the desired state is determined by the + number of CIS-nodes in the cluster that fulfil the VDU + requirements.as specified in the respective + declarative descriptor. It triggers actions toward the + CIS to align the actual to the desired state. + Monitoring the actual state includes monitoring the + number of MCIO instances available at any specific + point in time. In addition, an MCIO controller + maintains properties and runtime information on the + MCIO instances which have been created based on the + same VDU. The McioInfo data structure provides the + runtime information on the MCIOs obtained from the + MCIO controller. + + NOTE: There are different types of MCIOs. The set of + VNFC instances based on the same VDU is represented + by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type + of MCIO, e.g. a POD. + + Runtime information of the set of OS containers + realizing an individual VNFC instance is not part of + the McioInfo data structure; such runtime information + is provided in the ResourceHandle data structure + referenced from the VnfcResourceInfo. The McioInfo + does not provide runtime information of a constituent + VNFC instance created based on a specific VDU. + + NOTE 1: The type of MCIO as specified in the + declarative descriptor of the MCIO, and that can be + read from + the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the + “kind” property of the declarative descriptor. + NOTE 2: If the attribute additionalInfo is present, it + may contain runtime information on the actual and + desired state of the MCIO(s). + NOTE 3: When the container infrastructure service is a + Kubernetes® instance, the mcioId is the combined + values from the kind and name fields of the Kubernetes resource object, separated by a slash. + Example: "Deployment/abcd". + NOTE 4: When the container infrastructure service is a + Kubernetes® instance, the mcioName is the name + field of the resource object. + type: object + required: + - mcioId + - mcioName + - mcioNamespace + - vduId + - cismId + - mcioType + - desiredInstances + - availableInstances + properties: + mcioId: + description: > + An identifier with the intention of being globally + unique. + type: string + mcioName: + description: | + Human readable name of this MCIO. See note 4. + type: string + mcioNamespace: + description: | + Namespace of this MCIO. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cismId: + description: > + An identifier with the intention of being globally + unique. + type: string + mcioType: + description: > + The type of MCIO. Specific values, their semantics + and associated MCIO types are defined in clause + 5.5.4.9. Additional values are also permitted. See + note 1. + type: string + enum: + - Deployment + - Statefulset + - DaemonSet + desiredInstances: + description: | + Number of desired MCIO instances. + type: integer + availableInstances: + description: | + Number of available MCIO instances. + type: integer + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of the + certificate(s) that this MCIO instance uses. + Shall be present when using in delegation mode. + Otherwise shall not be present. This attribute + shall be supported when delegation mode in + certificate management is applicable. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfPaasServiceInfo: + description: > + Information on the PaaS Services assigned and used by + the VNF instance. + type: array + items: + description: > + This type provides input information about a PaaS + Service that is used by a VNF instance. The + PaasServiceInfo is comprised of various sets of + information. Some information comes from the VNFD, + other information comes from the PaaS Service assets + provided by the NFVO to the VNFM, and other + information is provided at runtime information about + the usage of the PaaS Service. + type: object + required: + - id + - paasServiceId + - paasServiceType + - paasServiceRequestId + - paasServiceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceType: + description: >- + The type of PaaS Service. The value of this + attribute is expected to be matched against values + of the registered PaaS Services in the PSR. + type: string + paasServiceVersion: + description: | + A version. + type: string + paasServiceRequestId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + paasServiceHandle: + description: > + This type provides information enabling the access + and use of the PaaS Service by the VNF instance. + The type and format of the handle depends on the + form that the PaaS Service is formed. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + extra: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + indicators: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + instantiate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + terminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + heal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + operate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + createSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + revertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeCurrentVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperationLinks: + description: > + Links to the most recent LCM operation occurrences related + to this resource. See note 9. + type: object + properties: + recentVnfLcmOperation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmInstantiation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmTerminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmHeal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmModifyInfo: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmCreateSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmRevertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmSelectDplMods: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualVnfInstance.Get.200: + description: > + 200 OK + + + Shall be returned when information about an individual VNF instance has + been read successfully. + + The response body shall contain a representation of the VNF instance, as + defined in clause 5.5.2.2. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + ETag: + description: > + Used to provide the current entity-tag for the selected resource + representation. It can be sent in "200 OK", "201 Created" and "204 + No Content" responses. + style: simple + schema: + type: string + Last-Modified: + description: > + Used to provide a timestamp indicating the date and time at which + the server believes the selected resource representation was last + modified. It can be sent in "200 OK", "201 Created" and "204 No + Content" responses. + style: simple + schema: + type: string + format: date-time + content: + application/json: + schema: + description: "This type represents a VNF instance.\nNOTE:\tClause B.3.2 provides examples illustrating the relationship among the different run-time \n information elements (CP, VL and link ports) used to represent the connectivity of a VNF.\n\nNOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist between \n the previous and the newly referred VNF package, i.e. when the new VNFD is changed with \n respect to the previous VNFD in other aspects than merely referencing to other VNF software \n images. In order to avoid misalignment of the VnfInstance with the current VNF's on-boarded \n VNF Package, the values of attributes in the VnfInstance that have corresponding attributes \n in the VNFD shall be kept in sync with the values in the VNFD.\nNOTE 2:\tETSI GS NFV-SOL 001 [14] specifies the structure and format of the VNFD based on TOSCA specifications. NOTE 3:\tVNF configurable properties are sometimes also referred to as configuration parameters applicable \n to a VNF. Some of these are set prior to instantiation and cannot be modified if the VNF is instantiated, \n some are set prior to instantiation (are part of initial configuration) and can be modified later, \n and others can be set only after instantiation. The applicability of certain configuration may \n depend on the VNF and the required operation of the VNF at a certain point in time.\nNOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes \n of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared in the VNFD with a defined \n initial value. The defined initial values can be declared in the VNFD, and/or, in case of \"metadata\", \n obtained from the \"CreateVnfRequest\" structure. Child attributes of \"vnfConfigurableProperties\", \n \"metadata\" and \"extensions\" that have no defined initial value shall not be created, in order to be \n consistent with the semantics of the JSON Merge Patch method (see IETF RFC 7396) that interprets null \n values as deletion request.\nNOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a \n multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same \n VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed \n multi-site VL instance (refer to clause 5.5.3.3).\nNOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity, they shall \n not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\nNOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing \n the trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\nNOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the \n VNF LCM operation explicitly indicates the scale level for the aspect.\nNOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n" + type: object + required: + - id + - vnfdId + - vnfProvider + - vnfProductName + - vnfSoftwareVersion + - vnfdVersion + - instantiationState + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfInstanceName: + description: > + Name of the VNF instance. This attribute can be modified with + the PATCH method. + type: string + vnfInstanceDescription: + description: > + Human-readable description of the VNF instance. This attribute + can be modified with the PATCH method. + type: string + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfProvider: + description: > + Provider of the VNF and the VNFD. The value is copied from the + VNFD. + type: string + vnfProductName: + description: > + Name to identify the VNF Product. The value is copied from the + VNFD. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + vimConnectionInfo: + description: > + Information about VIM or CISM connections to be used for + managing the resources for the VNF instance. The keys of the + map, each of which identifies information about a particular + VIM connection, are managed by the NFVO and referenced from + other data structures via the "vimConnectionId" attribute. + This attribute shall only be supported and present if - the + resources of at least of the VNFCs are managed by a VIM and + VNF-related resource management in direct mode is applicable. + - the resources of at least of the VNFCs are managed by a + CISM. This attribute can be modified with the PATCH method. If + VIM connection information is provisioned to the VNFM by means + outside the scope of the present document, the information in + the "vimConnectionInfo" attribute provides necessary + information for binding the VnfInstance representing the + "Individual VNF instance" to the applicable VIM connection + information used to perform resource management for the VNF + instance. See also the definition of the "VimConnectionInfo" + in clause 4.4.1.6. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines the + structure of the "interfaceInfo" and "accessInfo" + attributes, based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values is + expected to change over time as new types or versions of + VIMs become available. The ETSI NFV registry of + VIM-related information provides access to information + about VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The structure of + the registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + cirConnectionInfo: + description: > + Information about the CIR connection for managing OS container + images for the VNF instance. Shall be present when all or part + of the VNF is realized by a set of OS containers and shall be + absent otherwise. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines the + structure of the "interfaceInfo" and "accessInfo" + attributes, based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values is + expected to change over time as new types or versions of + VIMs become available. The ETSI NFV registry of + VIM-related information provides access to information + about VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The structure of + the registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + mciopRepositoryInfo: + description: > + Information about the MCIOP repository for the VNF instance. + Shall be present when all or part of the VNF is realized by a + set of OS containers and shall be absent otherwise. See note + 1. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines the + structure of the "interfaceInfo" and "accessInfo" + attributes, based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values is + expected to change over time as new types or versions of + VIMs become available. The ETSI NFV registry of + VIM-related information provides access to information + about VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The structure of + the registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + certificateInfo: + description: > + This type provides input information related to certificate + and certificate management. + type: object + required: + - id + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + certificateConfigurationInfo: + description: > + This type provides input information related to + certificate management. + type: object + required: + - securityPolicy + properties: + certificateBaseProfile: + description: Information for certificate profile. + type: array + items: + description: > + NOTE: At least one overriding attributes shall be + present, otherwise shall be absent. + + This type provides input information to override + certificate base profile for certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + issuer: + description: Issuer of certificates. See note. + type: string + issuerUniqueIdentifier: + description: > + An identifier with the intention of being + globally unique. + type: string + subject: + description: > + This type provides input information related to + the subject of the certificate. + + NOTE: At least one overriding attributes shall + be present, otherwise shall be absent. + type: object + properties: + commonName: + description: > + Information of the certification target + subject FQDN. Can be set empty when this + certificate is used for encrypted + communication using IP address. See note. + type: string + organization: + description: >- + Information of the certification target + subject Organization. See note. + type: string + country: + description: >- + Information of the certification target + subject Country. See note. + type: string + state: + description: >- + Information of the certification target + subject State. See note. + type: string + locality: + description: >- + Information of the certification target + subject Locality. See note. + type: string + emailAddress: + description: >- + Information of the certification contact + email address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of being + globally unique. + type: string + basicConstraints: + description: Basic constraints of certificates. See note. + type: string + issuerAltName: + description: >- + Alternative name of issuer of certificates in + this NS. See note. + type: array + items: + type: string + subjectAltName: + description: > + Alternative name of subject of certificates. + Shall be present when this certificate is used + for encrypted communication using IP address and + subjectAltName attribute of + CertificateBaseProfile in CertificateDesc of + VNFD is empty (see ETSI GS NFV-IFA 011 [14], + clause 7.1.19.4). See note. + type: array + items: + type: string + nameConstraints: + description: Name constraints of certificates. See note. + type: array + items: + type: string + securityPolicy: + description: >- + Information for security policy to be satisfied for + certificate. + type: array + items: + description: > + This type provides input information related to + security policy for certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + maxValidityPeriod: + description: Allowed max validity period for certificates. + type: number + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: number + delegationSupportedCertificateManagements: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + cmfInfo: + description: > + This type provides input information related to CMF + for certificate management. + type: object + required: + - id + - endPoint + - supportedProtocol + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + endPoint: + description: End point of CMF instance. + type: object + properties: + 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 + link: + description: > + This type represents a link to a resource + using an absolute URI. + type: object + required: + - href + properties: + href: + description: > + String formatted according to IETF RFC + 3986. + type: string + supportedProtocol: + description: Supported protocols by CMF instance. + type: array + items: + description: Supported protocol by CMF instance. + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + certificateChain: + description: Certificate chain that this CMF provides. + type: array + items: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + certificateContents: + description: > + Information for contents of issued certificates. The + information contained in this attribute may be updated + over time during the VNF LCM, e.g., certificate(s) + renewal. + type: array + items: + description: > + This type provides input information related to + certificate content. + + NOTE: The CertificateDesc data type is defined in clause + 7.1.19.2 of ETSI GS NFV IFA 011 [10]. + type: object + required: + - id + - certificateDescId + - certificateType + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + certificateDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + certificateType: + description: Type of this certificate. + type: string + enum: + - VNFCI_CERT + - VNFOAM_CERT + supportedCertificateManagements: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + version: + description: | + A version. + type: string + serialNumber: + description: Serial number of this certificate. + type: integer + signatureAlgorithm: + description: Algorithm of this certificate's signature. + type: string + issuer: + description: Issuer of this certificate. + type: string + notBefore: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + notAfter: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + subject: + description: Subject of this certificate. + type: string + publicKeyAlgorithm: + description: Algorithm of this certificate's public key. + type: string + publicKey: + description: Public key of this certificate. + type: string + certificateExtensions: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + instantiationState: + description: > + The instantiation state of the VNF. Permitted values: - + NOT_INSTANTIATED: The VNF instance is terminated or not + instantiated. - INSTANTIATED: The VNF instance is + instantiated. + type: string + enum: + - NOT_INSTANTIATED + - INSTANTIATED + instantiatedVnfInfo: + description: > + Information specific to an instantiated VNF instance. This + attribute shall be present if the instantiateState attribute + value is INSTANTIATED. + type: object + required: + - flavourId + - vnfState + properties: + flavourId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfState: + description: > + STARTED: The VNF instance is up and running. STOPPED: The + VNF instance has been shut down. + type: string + enum: + - STARTED + - STOPPED + vnfPowerState: + description: > + This type represents information about the power state of + a VNF instance. + type: object + required: + - powerProfileId + - name + properties: + powerProfileId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + name: + description: | + Name of the power profile as provided in the VNFD. + type: string + powerConsumptionInfo: + description: > + This type represents information about estimated power + consumption of the resources associated with the power + profile, as provided in the VNFD. + type: object + required: + - minPowerConsumption + - maxPowerConsumption + - averagePowerConsumption + properties: + minPowerConsumption: + description: > + Minimum power consumption of this power profile. + Unit is KW/h. + type: integer + maxPowerConsumption: + description: > + Maximum power consumption of this power profile. + Unit is KW/h. + type: integer + averagePowerConsumption: + description: > + Average power consumption of this power profile. + Unit is KW/h. + type: integer + scaleStatus: + description: > + Scale status of the VNF, one entry per aspect. Represents + for every scaling aspect how "big" the VNF has been + scaled w.r.t. that aspect. + + This attribute shall be present if the VNF supports + scaling. See clause B.2 for an explanation of VNF scaling. + + For an aspect that has not been deployed because the + related deployableModule has not been selected, it + indicates the scale level that has been requested in the + instantiation or in a scaling operation, or, if none has + been requested in any of them, the scale level applicable + to the aspect based on the default instantiation level. + See note 8. + type: array + items: + description: > + This type represents the scale level of a VNF instance + related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being globally + unique. + type: string + maxScaleLevels: + description: > + Maximum allowed scale levels of the VNF, one entry per + aspect. This attribute shall be present if the VNF + supports scaling. + type: array + items: + description: > + This type represents the scale level of a VNF instance + related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being globally + unique. + type: string + selectedDeployableModule: + description: > + References a currently selected deployable module, as + defined in the VNFD, that has already completed the + instantiation of its VNFCs. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + resourceCapacityDefinition: + description: > + Shows current values of VDU attributes related to resource + capacity, if different to the default values from the + VNFD, as indicated in the (one or more) request(s) of all + completed VNF LCM operation(s) that contain this + attribute. If an attribute value has been modified + multiple times, only the last value is shown. The values + indicated in this attribute are applicable to all VNFC + instances based on the VDU to which the + resourceCapacityDefinition is related. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes. + + * NOTE: Resource definitions not related to a VDU are + not considered in this version of the present document. + type: object + required: + - type + properties: + tag: + description: > + Tag assigned by the issuer of a VNF LCM operation + request that contains this data type with values to + be applied to a VDU. It is used for tracking + purposes. + + The tag is preserved in the run time record as long + as at least one value of the capacity related + attributes associated with that tag is still valid, + i.e., it has not been modified by a later VNF LCM + operation request. + + At most one tag can be included when the data type + is used in a VNF LCM operation request. + + When the data type is used in the VnfInstance data + type it may contain multiple tags, namely those + provided in VNF LCM requests, if at least one of the + values provided in that request associated to that + tag is still applicable in the VNFCs created from + this VDU, i.e., it has not been modified by a later + request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: | + Type of the resource definition referenced. + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + osContainerDescData: + description: > + Indicates values for resource capacity related + attributes in an OsContainerDesc. It shall be + present when the attribute 'type' indicates + OSCONTAINER and absent otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of an OsContainer resource. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for the + container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for the + container expressed in the same units as + specified in the + requested_memory_resources_valid_values + property in VNFD (clause 6.8.12 in ETSI GS + NFV-SOL 001 [14]) for this container + descriptor. See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources of the + type indicated in the key. The key is a string + that identifies an extended resource indicated + in the extended_resource_requests property in + the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 + [14]) for this container descriptor. The value + is an integer that indicates the required + amount for a particular extended resource. See + note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container can + maximally use in milli-CPU. See note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required for all + the hugepages of the size indicated in the + key. The key is a string and corresponds to + one of the values of the hugepage sizes + indicated in the huge_pages_resources property + in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL + 001 [14]) for this container descriptor. The + value is a number that indicates the required + total size expressed in the same units as in + the huge_pages_resource property in the VNFD + (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) + that indicates the valid values for required + total size for the particular hugepage size. + See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or + OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores + are requested to be allocated to logical + CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states of + virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual compute + resource of a VM. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required for all + the hugepages of the size indicated in the key. + The key is a string and corresponds to one of + the values of the hugepage sizes indicated in + the huge_pages_requirements property in the VNFD + (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for + this virtual compute descriptor. The value is a + numberthat indicates the required total size + expressed in the same units as in the + huge_pages_requirements property in the VNFD + (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) + that indicates the valid vaues for required + total size for the particular hugepage size. See + note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores + are requested to be allocated to logical CPU + cores according to the + cpuOperationalPowerStates attribute. In case + of "DYNAMIC", the CPU power states of + virtual CPU cores can be allocated to + logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size related + attribute in an VirtualStorageDesc. It shall be + present when the attribute 'type' indicates STORAGE + and absent otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual storage + resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + extCpInfo: + description: > + Information about the external CPs exposed by the VNF + instance. When trunking is enabled, the list of entries + includes both, external CPs corresponding to parent ports + of a trunk, and external CPs associated to sub-ports of a + trunk.See note 7. + type: array + items: + description: "This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n" + type: object + required: + - id + - cpdId + - cpConfigId + - cpProtocolInfo + oneOf: + - required: + - associatedVnfcCpId + - required: + - associatedVipCpId + - required: + - associatedVnfVirtualLinkId + properties: + id: + 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 + cpConfigId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + cpProtocolInfo: + description: | + Network protocol information for this CP. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and protocol(s) + associated to the network address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned to a + virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and + been associated to the CP. + type: array + items: + type: string + extLinkPortId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + associatedVnfcCpId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + associatedVipCpId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + associatedVirtualCpId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + associatedVnfVirtualLinkId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceInfo” structure + that provides the specification of the interface to + attach the connection point to a secondary container + cluster network. See notes 3 and 4. + + It shall be present if the external CP is associated + to a VNFC realized by one or a set of OS containers + and is connected to a secondary container cluster + network. It shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" structure + that provides the information of the certificate(s) + that this VNF CP instance uses. Shall be present + when using in delegation-mode. Otherwise shall not + be present. This attribute shall be supported when + delegation mode in certificate management is + applicable. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + cpSecurityGroupInfo: + description: > + This type provides the list of active security group + rules applied to an external CP instance. The type + identifies which "SecurityGroupRule" specified in + the VNFD are activated and the values of its + attributes. + type: object + required: + - securityGroupRuleId + - etherType + - protocol + - portRangeMin + - portRangeMax + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + description: + description: > + Human readable description of the security group + rule. + type: string + etherType: + description: > + Indicates the protocol carried over the Ethernet + layer. Permitted values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + protocol: + description: > + Indicates the protocol carried over the IP + layer. Permitted values: any protocol defined in + the IANA protocol registry (refer to clause + 9.10.1.2 ofd ETSI GS NFV-SOL 001 for further + information). + type: string + portRangeMin: + description: > + Value for the minimum port number in the range + that is matched by the security group rule. + type: integer + portRangeMax: + description: > + Value for the maximum port number in the range + that is matched by the security group rule. + type: integer + vipCpInfo: + description: > + VIP CPs that are part of the VNF instance. Shall be + present when that particular VIP CP of the VNFC instance + is associated to an external CP of the VNF instance. May + be present otherwise. + type: array + minItems: 1 + items: + description: "This type provides information related to virtual IP (VIP) CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n" + type: object + required: + - cpInstanceId + - cpdId + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There shall be one + cpProtocolInfo for layer 3. There may be one + cpProtocolInfo for layer 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and protocol(s) + associated to the network address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned to a + virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and + been associated to the CP. + type: array + items: + type: string + associatedVnfcCpIds: + description: > + Identifiers of the VnfcCps that share the virtual IP + address allocated to the VIP CP instance. See note. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + virtualCpInfo: + description: > + Virtual CPs that are part of the VNF instance. Shall be + present when a particular Virtual CP is associated to an + external CP of the VNF instance. May be present otherwise. + type: array + items: + description: > + This type provides information related to a virtual CP + instance of a VNF. + + NOTE 1: A consumer of the VNF LCM interface can learn + the actual VNFC instances implementing the service + accessible via the virtual CP instance by querying the "vnfcResourceInfo" from the "InstantiatedVnfInfo" + and filtering by corresponding "vduIds" values. + NOTE 2: The information can be omitted because it is + already available as part of the external CP information + in the + VnfExtCpInfo structure. + type: object + required: + - cpInstanceId + - cpdId + - resourceHandle + - vduIds + properties: + cpInstanceId: + 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 + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There shall be one + cpProtocolInfo for each layer protocol supported. + This attribute may be omitted if the virtual CP is + exposed as an external CP. See note 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and protocol(s) + associated to the network address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned to a + virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and + been associated to the CP. + type: array + items: + type: string + vduIds: + description: > + Reference to the VDU(s) which implement the service + accessible via the virtual CP instance. See note 1. + type: array + minItems: 1 + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + additionalServiceInfo: + description: > + Additional service identification information of the + virtual CP instance. + type: array + items: + description: > + This type provides additional service information + of the virtual CP instance used to expose + properties of the virtual CP to NFV-MANO. + + NOTE: This attribute shall only be present if + additional information is needed to identify the + service + termination within the VNF, such as for example a URL path information in an HTTP request required + to allow a single virtual CP IP address to be used for several HTTP based services that use the + same port number. + type: object + required: + - portInfo + properties: + portInfo: + description: > + Service port numbers exposed by the virtual CP + instance. + minItems: 1 + type: array + items: + description: > + This type describes the service identifying + port properties exposed by the virtual CP + instance. + type: object + required: + - name + - port + - portConfigurable + properties: + name: + description: > + The name of the port exposed by the + virtual CP instance. + type: string + protocol: + description: > + The L4 protocol for this port exposed by + the virtual CP instance. + + Permitted values: - TCP - UDP - SCTP + type: string + enum: + - TCP + - UDP + - SCTP + port: + description: > + The L4 port number exposed by the + virtual CP instance. + type: integer + portConfigurable: + description: > + The Boolean is a data type having two + values (true and false). + type: boolean + serviceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + extVirtualLinkInfo: + description: > + Information about the external VLs the VNF instance is + connected to. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. Information about + the resource is available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource provider. + See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available from + the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be present + if the resource is managed by a CISM and + it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the current CP + configuration information for the connection of + external CPs to the external virtual link. See + note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be + configured on the CP instances created from + the respective CPD. + + The key of the map which identifies the + individual VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. + + The entries shall be applied by the VNFM + according to the rules of JSON Merge Patch + (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. + In case of deleting an external CP, the list + of instances to be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided + link port, or a network attachment + definition resource of secondary container + cluster network, or network address + information per instance of an external + connection point. In the case of VM-based + deployment of the VNFC exposing the external + CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of + the VNFC exposing the external CP, the VNFM + shall use the network attachment definition + resource of secondary container cluster + network when connecting the CP to the + external VL. + + * NOTE 1: The following conditions apply to + the attributes "linkPortId" and + "cpProtocolData" for an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to + the attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more + than one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of + being globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create + a dedicated link port for the external + CP. If set to True, the VNFM shall + create a link port. If set to False, the + VNFM shall not create a link port. This + attribute is only applicable for + external CP instances without a floating + IP address that expose a VIP CP instance + for which a dedicated IP address is + allocated. It shall be present in that + case and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceData” structure that + provides the specification of the + interface to attach the external CP to a + secondary container cluster network. It + is only applicable if the external CP is + connected or to be connected to a + secondary container cluster network. It + shall not be present if the external CP + is related to a virtual network not + categorized as secondary container + cluster network. See notes 2, 3 and 4. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects + the CP to a VL and the domain names for + the external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security + groups. The parameters identify which + "SecurityGroupRule" specified in the + VNFD is activated/deactivated and for an + activated security group rule the values + of attributes defined in the VNFD that + can be overriden such as "portRangeMin" + and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extNetAttDefResource: + description: > + Network attachment definition resources that provide + the specification of the interface to attach + connection points to this VL. + type: array + items: + description: > + This type contains information related to a + network attachment definition resource that + provides the specification of the interface used + to connect one or multiple connection points to a + secondary container cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of being + globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. Information about + the resource is available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource provider. + See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available from + the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be present + if the resource is managed by a CISM and + it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated to + this network attachment definition resource. + Shall be present when the network attachment + definition resource is used for external + connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to this + network attachment definition resource. May be + present when the network attachment + definition resource is used for internal + connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and been + associated to the CP. + type: array + items: + type: string + extManagedVirtualLinkInfo: + description: > + Information about the externally-managed internal VLs of + the VNF instance. See notes 5 and 6. + type: array + items: + description: > + This type provides information about an + externally-managed virtual link. Note: Both + "vnfLinkPort" and "vnfNetAttDefResource" attributes can + be present in an "ExtManagedVirtualLinkInfo" to + indicate that a single internal virtual link is providing connectivity for both VM-based and container-based + VNFCs. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + vnfLinkPorts: + description: | + Link ports of this VL. See note. + type: array + items: + description: > + This type represents a link port of an internal VL + of a VNF. + + NOTE 1: Either cpInstanceId with cpInstanceType + set to "EXT_CP" or any combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides + examples for configurations where both + vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is scoped + by the value of "vimConnectionId" in the + "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. Information about + the resource is available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource provider. + See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available from + the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be present + if the resource is managed by a CISM and + it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vnfNetAttDefResource: + description: > + Network attachment definition resources that provide + the specification of the interface to attach + connection points to this VL. See note. + type: array + items: + description: > + This type contains information related to a + network attachment definition resource that + provides the specification of the interface used + to connect one or multiple connection points to a + secondary container cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of being + globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. Information about + the resource is available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource provider. + See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available from + the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be present + if the resource is managed by a CISM and + it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated to + this network attachment definition resource. + Shall be present when the network attachment + definition resource is used for external + connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to this + network attachment definition resource. May be + present when the network attachment + definition resource is used for internal + connectivity by the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + extManagedMultisiteVirtualLinkId: + description: > + An identifier with the intention of being globally + unique. + type: string + routingResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + monitoringParameters: + description: | + Active monitoring parameters. + type: array + items: + description: > + This type represents a monitoring parameter that is + tracked by the VNFM, + type: object + required: + - id + - performanceMetric + properties: + id: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + name: + description: > + Human readable name of the monitoring parameter, as + defined in the VNFD. + type: string + performanceMetric: + description: > + Performance metric that is monitored. This attribute + shall contain the related "Measurement Name" value + as defined in clause 7.2 of ETSI GS NFV-IFA 027. + type: string + localizationLanguage: + description: > + Information about localization language of the VNF + (includes e.g. strings in the VNFD). The localization + languages supported by a VNF can be declared in the VNFD, + and localization language selection can take place at + instantiation time. The value shall comply with the format + defined in IETF RFC 5646. + type: string + vnfcResourceInfo: + description: > + Information about the virtualised compute and storage + resources used by the VNFCs of the VNF instance. + type: array + items: + description: "This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure of\n information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n a) For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n b) For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\nNOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on \n TOSCA specifications.\nNOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an \n internal VL that exposes an external CP. A VNFC CP is \"exposed as\" an external \n CP if it is connected directly to an external VL.\nNOTE 3:\tThe information can be omitted because it is already available as part of the \n external CP information.\nNOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\"\n structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVnfc\" structure in the VNF LCM operation occurrence notifications\n or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\nNOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment\n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. \nNOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n" + type: object + required: + - id + - vduId + - computeResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + storageResourceIds: + description: > + References to the VirtualStorage resources or + references to Storage MCIOs. The value refers to a + VirtualStorageResourceInfo item in the VnfInstance. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfcCpInfo: + description: > + CPs of the VNFC instance. Shall be present when that + particular CP of the VNFC instance is exposed as an + external CP of the VNF instance or is connected to + an external CP of the VNF instance. See note 2. May + be present otherwise. See note 7. + type: array + items: + type: object + required: + - id + - cpdId + properties: + id: + 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 + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + cpProtocolInfo: + description: > + Network protocol information for this CP. May + be omitted if the VNFC CP is exposed as an + external CP. See note 3. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + parentCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceInfo” + structure that provides the specification of + the interface to attach the connection point + to a secondary container cluster network. See + notes 5 and 6. It shall be present if the + internal CP is associated to a VNFC realized + by one or a set of OS containers and is + connected to a secondary container cluster + network. It shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of the + certificate(s) that this VNFC CP instance + uses. Shall be present when using in + delegation-mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate management + is applicable + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" structure + that provides the information of the certificate(s) + that this VNFC instance uses. Shall be present when + using in delegation-mode. Otherwise shall not be + present. This attribute shall be supported when + delegation mode in certificate management is + applicable. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfVirtualLinkResourceInfo: + description: > + Information about the virtualised network resources used + by the VLs of the VNF instance. See note 6. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used by an + internal VL instance in a VNF instance. + + Note: If only the value or the presence of this + attribute is changed in the "VnfVirtualLinkResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires including + a related "AffectedVirtualLink" structure in the VNF LCM operation occurrence notifications or the + "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + reservationId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfLinkPorts: + description: > + Links ports of this VL. Shall be present when the + linkPort is used for external connectivity by the + VNF (refer to VnfLinkPortInfo). May be present + otherwise. + type: array + items: + description: > + This type represents a link port of an internal VL + of a VNF. + + NOTE 1: Either cpInstanceId with cpInstanceType + set to "EXT_CP" or any combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides + examples for configurations where both + vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is scoped + by the value of "vimConnectionId" in the + "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. Information about + the resource is available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource provider. + See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available from + the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be present + if the resource is managed by a CISM and + it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + virtualStorageResourceInfo: + description: > + Information on the virtualised storage resource(s) used as + storage for the VNF instance. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. + + Note: If only the value or the presence of this + attribute is changed in the "VirtualStorageResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires + including a related "AffectedVirtualStorage" structure in the VNF LCM operation occurrence + notifications or the "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - virtualStorageDescId + - storageResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + reservationId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + mcioInfo: + description: > + Information on the MCIO(s) representing VNFC instance(s) + realized by one or a set of OS containers and created from + the same VDU for the VNF instance. + type: array + items: + description: > + This type provides information about an MCIO + representing the set of VNFC instances realized by one + or a set of OS containers which have been created based + on the same VDU. Within the CISM, an MCIO controller + monitors the actual state of an MCIO representing the + set of VNFC instances realized by one or a set of OS + containers and compare it to the desired state For an + MCIO related to a VDU that has the attribute + isNumOfInstancesClusterBased set to FALSE the desired + state is specified in the respective declarative + descriptor. For an MCIO related to a VDU that has the + attribute isNumOfInstancesClusterBased set to TRUE, the + desired state is determined by the number of CIS-nodes + in the cluster that fulfil the VDU requirements.as + specified in the respective declarative descriptor. It + triggers actions toward the CIS to align the actual to + the desired state. Monitoring the actual state includes + monitoring the number of MCIO instances available at + any specific point in time. In addition, an MCIO + controller maintains properties and runtime information + on the MCIO instances which have been created based on + the same VDU. The McioInfo data structure provides the + runtime information on the MCIOs obtained from the MCIO + controller. + + NOTE: There are different types of MCIOs. The set of + VNFC instances based on the same VDU is represented + by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type + of MCIO, e.g. a POD. + + Runtime information of the set of OS containers + realizing an individual VNFC instance is not part of + the McioInfo data structure; such runtime information + is provided in the ResourceHandle data structure + referenced from the VnfcResourceInfo. The McioInfo does + not provide runtime information of a constituent VNFC + instance created based on a specific VDU. + + NOTE 1: The type of MCIO as specified in the declarative + descriptor of the MCIO, and that can be read from + the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the + “kind” property of the declarative descriptor. + NOTE 2: If the attribute additionalInfo is present, it + may contain runtime information on the actual and + desired state of the MCIO(s). + NOTE 3: When the container infrastructure service is a + Kubernetes® instance, the mcioId is the combined + values from the kind and name fields of the Kubernetes resource object, separated by a slash. + Example: "Deployment/abcd". + NOTE 4: When the container infrastructure service is a + Kubernetes® instance, the mcioName is the name + field of the resource object. + type: object + required: + - mcioId + - mcioName + - mcioNamespace + - vduId + - cismId + - mcioType + - desiredInstances + - availableInstances + properties: + mcioId: + description: > + An identifier with the intention of being globally + unique. + type: string + mcioName: + description: | + Human readable name of this MCIO. See note 4. + type: string + mcioNamespace: + description: | + Namespace of this MCIO. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cismId: + description: > + An identifier with the intention of being globally + unique. + type: string + mcioType: + description: > + The type of MCIO. Specific values, their semantics + and associated MCIO types are defined in clause + 5.5.4.9. Additional values are also permitted. See + note 1. + type: string + enum: + - Deployment + - Statefulset + - DaemonSet + desiredInstances: + description: | + Number of desired MCIO instances. + type: integer + availableInstances: + description: | + Number of available MCIO instances. + type: integer + additionalInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" structure + that provides the information of the certificate(s) + that this MCIO instance uses. Shall be present when + using in delegation mode. Otherwise shall not be + present. This attribute shall be supported when + delegation mode in certificate management is + applicable. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfPaasServiceInfo: + description: > + Information on the PaaS Services assigned and used by the + VNF instance. + type: array + items: + description: > + This type provides input information about a PaaS + Service that is used by a VNF instance. The + PaasServiceInfo is comprised of various sets of + information. Some information comes from the VNFD, other + information comes from the PaaS Service assets provided + by the NFVO to the VNFM, and other information is + provided at runtime information about the usage of the + PaaS Service. + type: object + required: + - id + - paasServiceId + - paasServiceType + - paasServiceRequestId + - paasServiceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceType: + description: >- + The type of PaaS Service. The value of this + attribute is expected to be matched against values + of the registered PaaS Services in the PSR. + type: string + paasServiceVersion: + description: | + A version. + type: string + paasServiceRequestId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + paasServiceHandle: + description: > + This type provides information enabling the access + and use of the PaaS Service by the VNF instance. The + type and format of the handle depends on the form + that the PaaS Service is formed. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + additionalInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + indicators: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + instantiate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + terminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + heal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + operate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + createSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + revertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeCurrentVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperationLinks: + description: > + Links to the most recent LCM operation occurrences related to + this resource. See note 9. + type: object + properties: + recentVnfLcmOperation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmInstantiation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmTerminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmHeal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmModifyInfo: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmCreateSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmRevertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmSelectDplMods: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualVnfInstance.Patch.202: + description: > + 202 ACCEPTED + + + Shall be returned when the request has been accepted for processing. + + On success, the HTTP response shall include a "Location" HTTP header + that + + contains the URI of the newly-created "Individual VNF LCM operation + occurrence" + + resource corresponding to the operation. + + The response body shall be empty. + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + IndividualVnfInstance.Patch.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the "Individual VNF + instance" resource. + Typically, this is due to the fact that another LCM + operation is ongoing. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute should + convey more information about the error + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualVnfInstance.Patch.412: + description: | + 412 Precondition Failed + + Shall be returned upon the following error: A + precondition given in an HTTP request header is + not fulfilled. + Typically, this is due to an ETag mismatch, + indicating that the resource was modified by + another entity. + The response body should contain a + ProblemDetails structure, in which the "detail" + attribute should convey more information about the + error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + IndividualVnfInstance.Delete.204: + description: > + 204 NO CONTENT + + + Shall be returned when the "Individual VNF instance" resource and the + associated + + VNF identifier were deleted successfully. + + The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualVnfInstance.Delete.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that the "Individual + VNF instance" resource is in INSTANTIATED state. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + InstantiateVnfInstance.Post.202: + description: | + 202 ACCEPTED + + Shall be returned when the request has been accepted for processing + The response body shall be empty. + The HTTP response shall include a "Location" HTTP header that + contains the URI of the newly-created "Individual VNF LCM operation + occurrence" resource corresponding to the operation. + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + InstantiateVnfInstance.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that the "Individual + VNF instance" resource is in INSTANTIATED state, + or that a required (see note) child attribute of the + "extensions" attribute has not been set. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + ScaleVnfInstance.Post.202: + description: | + 202 ACCEPTED + + Shall be returned when the request has been accepted for processing. + The response body shall be empty. + The HTTP response shall include a "Location" HTTP header that + contains the URI of the newly-created "VNF LCM operation + occurrence" resource corresponding to the operation. + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Selectdeployablemodules.Post.202: + description: > + 202 ACCEPTED + + + Shall be returned when the request has been accepted for processing. + + The response body shall be empty. + + The HTTP response shall include a "Location" HTTP header that contains + the URI of the newly-created + + "Individual VNF LCM operation occurrence" resource corresponding to the + operation. + headers: + Location: + description: | + The resource URI of the created "Individual VNF LCM operation + occurrence" resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + ScaleVnfInstance.Post.404: + description: | + 404 NOT FOUND + + Shall be returned upon the following error: The API + producer did not find a current representation for the + target resource or is not willing to disclose that one + exists. + The general cause for this error and its handling is + specified in clause 6.4 of ETSI GS NFV-SOL 013 [8], + including rules for the presence of the response body. + Specifically in case of this task resource, the + response code 404 shall also be returned if the task + is not supported for the VNF instance represented by + the parent resource, which means that the task + resource consequently does not exist. + In this case, the response body shall be present, and + shall contain a ProblemDetails structure, in which the + "detail" attribute shall convey more information about + the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + ScaleVnfInstance.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that the "Individual + VNF instance" resource is in NOT_INSTANTIATED + state, that another lifecycle management operation is + ongoing, or that a required (see note) child attribute + of the "extensions" attribute has not been set. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + ScaleToLevelVnfInstance.Post.202: + description: | + 202 ACCEPTED + + Shall be returned when the request has been accepted for processing. + The response body shall be empty. + The HTTP response shall include a "Location" HTTP header that + contains the URI of the newly-created "VNF LCM operation + occurrence" resource corresponding to the operation. + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + ScaleToLevelVnfInstance.Post.404: + description: | + 404 NOT FOUND + + Shall be returned upon the following error: The API + producer did not find a current representation for the + target resource or is not willing to disclose that one + exists. + The general cause for this error and its handling is + specified in clause 6.4 of ETSI + GS NFV-SOL 013 [8], including rules for the + presence of the response body. + Specifically in case of this task resource, the + response code 404 shall also be returned if the task + is not supported for the VNF instance represented + by the parent resource, which means that the task + resource consequently does not exist. + In this case, the response body shall be present, + and shall contain a ProblemDetails structure, in + which the "detail" attribute shall convey more + information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + ScaleToLevelVnfInstance.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that the VNF + instance resource is in NOT_INSTANTIATED state, + that another lifecycle management operation is + ongoing, or that a required (see note) child attribute + of the "extensions" attribute has not been set. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + ChangeFlavourVnfInstance.Post.202: + description: | + 202 ACCEPTED + + Shall be returned when the request has been accepted for processing. + The response body shall be empty. + The HTTP response shall include a "Location" HTTP header that + contains the URI of the newly-created "VNF LCM operation + occurrence" resource corresponding to the operation. + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + ChangeFlavourVnfInstance.Post.404: + description: | + 404 NOT FOUND + + Shall be returned upon the following error: The API + producer did not find a current representation for the + target resource or is not willing to disclose that one + exists. + The general cause for this error and its handling is + specified in clause 6.4 of ETSI + GS NFV-SOL 013 [8], including rules for the + presence of the response body. + Specifically in case of this task resource, the + response code 404 shall also be returned if the task + is not supported for the VNF instance represented + by the parent resource, which means that the task + resource consequently does not exist. + In this case, the response body shall be present, + and shall contain a ProblemDetails structure, in + which the "detail" attribute shall convey more + information about the error + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + ChangeFlavourVnfInstance.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that the "Individual + VNF instance" resource is in NOT_INSTANTIATED + state, that another lifecycle management operation + is ongoing, or that a required (see note) child + attribute of the "extensions" attribute has not been + set. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + TerminateVnfInstance.Post.202: + description: | + 202 ACCEPTED + + Shall be returned when the request has been accepted for processing. + The response body shall be empty. + The HTTP response shall include a "Location" HTTP header that + contains the URI of the newly-created "VNF LCM operation + occurrence" resource corresponding to the operation. + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + TerminateVnfInstance.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that the "Individual + VNF instance" resource is in NOT_INSTANTIATED + state, that another lifecycle management operation is + ongoing, or that a required (see note) child attribute + of the "extensions" attribute has not been set. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + HealVnfInstance.Post.202: + description: | + 202 ACCEPTED + + Shall be returned when the request has been accepted for processing. + The response body shall be empty. + The HTTP response shall include a "Location" HTTP header that + contains the URI of the newly-created "VNF LCM operation + occurrence" resource corresponding to the operation. + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + HealVnfInstance.Post.404: + description: | + 404 NOT FOUND + + Shall be returned upon the following error: The API + producer did not find a current representation for the + target resource or is not willing to disclose that one + exists. + The general cause for this error and its handling is + specified in clause 6.4 of ETSI GS NFV-SOL 013 [8], + including rules for the presence of the response body. + Specifically in case of this task resource, the + response code 404 shall also be returned if the task + is not supported for the VNF instance represented by + the parent resource, which means that the task + resource consequently does not exist. + In this case, the response body shall be present, and + shall contain a ProblemDetails structure, in which the + "detail" attribute shall convey more information about + the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + HealVnfInstance.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that the "Individual + VNF instance" resource is in NOT_INSTANTIATED + state, that another lifecycle management operation is + ongoing, or that a required (see note) child attribute + of the "extensions" attribute has not been set. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + OperateVnfInstance.Post.202: + description: | + 202 ACCEPTED + + Shall be returned when the request has been accepted for processing. + The response body shall be empty. + The HTTP response shall include a "Location" HTTP header that + contains the URI of the newly-created "VNF LCM operation + occurrence" resource corresponding to the operation. + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + OperateVnfInstance.Post.404: + description: | + 404 NOT FOUND + + Shall be returned upon the following error: The API + producer did not find a current representation for + the target resource or is not willing to disclose that + one exists. + The general cause for this error and its handling is + specified in clause 6.4 of ETSI + GS NFV-SOL 013 [8], including rules for the + presence of the response body. + Specifically in case of this task resource, the + response code 404 shall also be returned if the + task is not supported for the VNF instance + represented by the parent resource, which means + that the task resource consequently does not exist. + In this case, the response body shall be present, + and shall contain a ProblemDetails structure, in + which the "detail" attribute shall convey more + information about the error + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + OperateVnfInstance.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that the VNF + instance resource is in NOT_INSTANTIATED + state, that another lifecycle management operation + is ongoing, or that a required (see note) child + attribute of the "extensions" attribute has not been + set. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + ChangeExtConnVnfInstance.Post.202: + description: | + 202 ACCEPTED + + Shall be returned when the request has been accepted for processing. + The response body shall be empty. + The HTTP response shall include a "Location" HTTP header that + contains the URI of the newly-created "VNF LCM operation + occurrence" resource corresponding to the operation. + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + ChangeExtConnVnfInstance.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: + The operation cannot be executed + currently, due to a conflict with the state of + the resource. + Typically, this is due to the fact that + another lifecycle management operation is + ongoing, or that a required (see note) child + attribute of the "extensions" attribute has + not been set. + The response body shall contain a + ProblemDetails structure, in which the + "detail" attribute shall convey more + information about the error + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + ChangeVnfpkgVnfInstance.Post.202: + description: > + 202 ACCEPTED + + + Shall be returned when the request has been accepted for processing. + + The response body shall be empty. + + The HTTP response shall include a "Location" HTTP header that contains + the URI of + + the newly-created "VNF LCM operation occurrence" resource corresponding + to the operation. + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + ChangeVnfpkgVnfInstance.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: + The operation cannot be executed + currently, due to a conflict with the state of + the resource. + Typically, this is due to the fact that + another lifecycle management operation is + ongoing. + The response body shall contain a + ProblemDetails structure, in which the + "detail" attribute shall convey more + information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + VnfLcmOpOccs.Get.200: + description: > + 200 OK + + + Shall be returned when status information for zero or more VNF lifecycle + management + + operation occurrences has been queried successfully. + + The response body shall contain in an array the status information about + zero or more + + VNF lifecycle operation occurrences, as defined in clause 5.5.2.13. + + If the "filter" URI parameter or one of the "all_fields", "fields" (if + supported), + + "exclude_fields" (if supported) or "exclude_default" URI parameters was + supplied in the request, + + the data in the response body shall have been transformed according to + the rules specified + + in clauses 5.2.2 and 5.3.2 of ETSI GS NFV-SOL 013, respectively. + + If the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 + of ETSI GS NFV-SOL 013 + + for this resource, inclusion of the Link HTTP header in this response + shall follow the provisions + + in clause 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: "This type represents a VNF lifecycle management operation occurrence.\nNOTE 1:\tThis allows the NFVO to obtain the information contained in the latest \n \"result\" notification if it has not received it due to an error or a \n wrongly configured subscription filter.\nNOTE 2:\tNot more than one of changedInfo and modificationsTriggeredByVnfPkgChange \n shall be present.\nNOTE 3:\tFor a particular affected VL, there shall be as many \"AffectedVirtualLink\" \n entries as needed for signalling the different types of changes, i.e. one \n per virtual link and change type. For instance, in the case of signaling \n affected VL instances involving the addition of a particular VL instance \n with links ports, one \"AffectedVirtualLink\" entry signals the addition of \n the VL by using the \"changeType\" attribute of \"AffectedVirtualLink\" structure \n equal to \"ADDED\", and another \"AffectedVirtualLink\" entry signals the addition \n of externally visible VNF link ports of the VL by using the \"changeType\" equal \n to \"LINK_PORT_ADDED\".\nNOTE 4:\tA coordination action has timed out if the VNFM has not been able to read the \n \"Individual coordination action\" resource within a timeout interval after requesting \n the coordination to be started or to be cancelled. The length of the timeout interval \n is defined by means outside the scope of the present document.\nNOTE 5: The list of rejected coordinations may be garbage collected if the LCM operation\n occurrence has reached a terminal state, i.e. one of \"COMPLETED\", \"FAILED\" and \"ROLLED_BACK\".\n" + type: object + oneOf: + - required: + - changedInfo + - required: + - modificationsTriggeredByVnfPkgChange + required: + - id + - operationState + - stateEnteredTime + - startTime + - vnfInstanceId + - operation + - isAutomaticInvocation + - isCancelPending + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + operationState: + description: > + STARTING: The LCM operation is starting. PROCESSING: The LCM + operation is currently in execution. COMPLETED: The LCM + operation has been completed successfully. FAILED_TEMP: The + LCM operation has failed and execution has stopped, but the + execution of the operation is not considered to be closed. + FAILED: The LCM operation has failed and it cannot be + retried or rolled back, as it is determined that such action + won't succeed. ROLLING_BACK: The LCM operation is currently + being rolled back. ROLLED_BACK: The LCM operation has been + successfully rolled back, i.e. The state of the VNF prior to + the original operation invocation has been restored as + closely as possible. + type: string + enum: + - STARTING + - PROCESSING + - COMPLETED + - FAILED_TEMP + - FAILED + - ROLLING_BACK + - ROLLED_BACK + stateEnteredTime: + description: > + Date-time stamp. Representation: String formatted according + to IETF RFC 3339. + type: string + format: date-time + startTime: + description: > + Date-time stamp. Representation: String formatted according + to IETF RFC 3339. + type: string + format: date-time + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + grantId: + description: | + An identifier with the intention of being globally unique. + type: string + operation: + description: > + The enumeration LcmOpType defines the permitted values to + represent VNF lifecycle operation types in VNF lifecycle + management operation occurrence resources and VNF lifecycle + management operation occurrence notifications. + + Value | Description ------|------------ INSTANTIATE | + Represents the "Instantiate VNF" LCM operation. SCALE | + Represents the "Scale VNF" LCM operation. SCALE_TO_LEVEL | + Represents the "Scale VNF to Level" LCM operation. + CHANGE_FLAVOUR | Represents the "Change VNF Flavour" LCM + operation. TERMINATE | Represents the "Terminate VNF" LCM + operation. HEAL | Represents the "Heal VNF" LCM operation. + OPERATE | Represents the "Operate VNF" LCM operation. + CHANGE_EXT_CONN | Represents the "Change external VNF + connectivity" LCM operation. MODIFY_INFO | Represents the + "Modify VNF Information" LCM operation. CREATE_SNAPSHOT | + Represents the "Create VNF Snapshot" LCM operation. + REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot" + LCM operation. CHANGE_VNFPKG | Represents the "Change + current VNF package" LCM operation. SELECT_DEPL_MODS | + Represents the “Select VNF deployable modules” LCM operation + type: string + enum: + - INSTANTIATE + - SCALE + - SCALE_TO_LEVEL + - CHANGE_FLAVOUR + - TERMINATE + - HEAL + - OPERATE + - CHANGE_EXT_CONN + - MODIFY_INFO + - CREATE_SNAPSHOT + - REVERT_TO_SNAPSHOT + - CHANGE_VNFPKG + - SELECT_DEPL_MODS + isAutomaticInvocation: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + operationParams: + description: > + Input parameters of the LCM operation. This attribute shall + be formatted according to the request data type of the + related LCM operation. In addition, the provisions in clause + 5.7 shall apply. + + The following mapping between operationType and the data + type of this attribute shall apply: * INSTANTIATE: + InstantiateVnfRequest * SCALE: ScaleVnfRequest * + SCALE_TO_LEVEL: ScaleVnfToLevelRequest * CHANGE_FLAVOUR: + ChangeVnfFlavourRequest * OPERATE: OperateVnfRequest * HEAL: + HealVnfRequest * CHANGE_EXT_CONN: + ChangeExtVnfConnectivityRequest * TERMINATE: + TerminateVnfRequest * MODIFY_INFO: VnfInfoModifications * + CREATE_SNAPSHOT: CreateVnfSnapshotRequest * + REVERT_TO_SNAPSHOT: RevertToVnfSnapshotRequest * + CHANGE_VNFPKG: ChangeCurrentVnfPkgRequest * + SELECT_DEPL_MODS: SelectVnfDeployableModulesRequest + type: object + isCancelPending: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + cancelMode: + description: > + Cancellation mode. GRACEFUL: If the VNF LCM operation + occurrence is in "PROCESSING" or "ROLLING_BACK" state, the + VNFM shall not start any new resource management operation + and shall wait for the ongoing resource management + operations in the underlying system, typically the VIM, to + finish execution or to time out. After that, the VNFM shall + put the operation occurrence into the FAILED_TEMP state. If + the VNF LCM operation occurrence is in "STARTING" state, the + VNFM shall not start any resource management operation and + shall wait for the granting request to finish execution or + time out. After that, the VNFM shall put the operation + occurrence into the ROLLED_BACK state. FORCEFUL: If the VNF + LCM operation occurrence is in "PROCESSING" or + "ROLLING_BACK" state, the VNFM shall not start any new + resource management operation, shall cancel the ongoing + resource management operations in the underlying system, + typically the VIM, and shall wait for the cancellation to + finish or to time out. After that, the VNFM shall put the + operation occurrence into the FAILED_TEMP state. If the VNF + LCM operation occurrence is in "STARTING" state, the VNFM + shall not start any resource management operation and put + the operation occurrence into the ROLLED_BACK state. + type: string + enum: + - GRACEFUL + - FORCEFUL + error: + description: > + The definition of the general "ProblemDetails" data + structure from IETF RFC 7807 is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807, + 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + resourceChanges: + description: > + This attribute contains information about the cumulative + changes to virtualised resources that were performed so far + by the LCM operation since its start, if applicable. + type: object + properties: + affectedVnfcs: + description: > + Information about VNFC instances that were affected + during the lifecycle operation. See note 1. + type: array + items: + description: "This type provides information about added, deleted, modified and temporary VNFCs.\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer \n (i.e. the NFVO) to assist in correlating the resource changes performed during \n the LCM operation with the granted resources in a specific Grant exchange, which \n is identified by the \"grantId\" available in the \"Individual VNF lifecycle management \n operation occurrence\" and the \"id\" in the \"Individual Grant\".\n" + type: object + required: + - id + - vduId + - changeType + - computeResource + properties: + id: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: > + Signals the type of change. Permitted values: * + ADDED * REMOVED * MODIFIED * TEMPORARY For a + temporary resource, an AffectedVnfc structure + exists as long as the temporary resource exists. + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + resourceDefinitionId: + description: > + An identifier that is unique within a limited + local scope other than above listed identifiers, + such as within a complex data structure or within + a request-response pair. Representation: string of + variable length. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + affectedVnfcCpIds: + description: > + Identifiers of CP(s) of the VNFC instance that + were affected by the change. Shall be present for + those affected CPs of the VNFC instance that are + associated to an external CP of the VNF instance. + May be present for further affected CPs of the + VNFC instance. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + addedStorageResourceIds: + description: > + References to VirtualStorage resources that have + been added. Each value refers to a + VirtualStorageResourceInfo item in the VnfInstance + that was added to the VNFC. It shall be provided + if at least one storage resource was added to the + VNFC. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + removedStorageResourceIds: + description: > + References to VirtualStorage resources that have + been removed. The value contains the identifier of + a VirtualStorageResourceInfo item that has been + removed from the VNFC, and might no longer exist + in the VnfInstance. It shall be provided if at + least one storage resource was removed from the + VNFC. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + affectedVirtualLinks: + description: > + Information about VL instances that were affected during + the lifecycle operation. See notes 1 and 3. + type: array + items: + description: "This type provides information about added, deleted, modified and temporary VLs, and added or removed VNF link ports.\nNOTE 1:\tWhen signalling the addition (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) of VNF link ports, \n the \"networkResource\" and \"resourceDefinitionId\" attributes refer to the affected virtual link \n instance, not the link port instance. The resource handles of the affected VNF link ports can be \n found by dereferencing the identifiers in the \"vnfLinkPortIds\" attribute.\nNOTE 2:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to \n assist in correlating the resource changes performed during the LCM operation with the granted \n resources in a specific Grant exchange, which is identified by the \"grantId\" available in the \n \"Individual VNF lifecycle management operation occurrence\" and the \"id\" in the \"Individual Grant\".\n" + type: object + required: + - id + - vnfVirtualLinkDescId + - changeType + - networkResource + properties: + id: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: "Signals the type of change.\nPermitted values: -\tADDED -\tREMOVED -\tMODIFIED -\tTEMPORARY -\tLINK_PORT_ADDED -\tLINK_PORT_REMOVED For a temporary resource, an AffectedVirtualLink structure exists as long as the temporary resource exists. See note 1.\n" + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + - LINK_PORT_ADDED + - LINK_PORT_REMOVED + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + vnfLinkPortIds: + description: > + Identifiers of the link ports of the affected VL + related to the change. Each identifier references + a "VnfLinkPortInfo" structure. + + Shall be set when changeType is equal to + "LINK_PORT_ADDED" or "LINK_PORT_REMOVED", and the + related "VnfLinkPortInfo" structures are present + (case "added") or have been present (case + "removed") in the "VnfVirtualLinkResourceInfo" or + "ExtManagedVirtualLinkInfo" structures that are + represented by the "vnfVirtualLinkResource¬Info" + or "extManagedVirtualLinkInfo" attribute in the + "VnfInstance" structure. See note 1. + type: array + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + resourceDefinitionId: + description: > + An identifier that is unique within a limited + local scope other than above listed identifiers, + such as within a complex data structure or within + a request-response pair. Representation: string of + variable length. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + affectedExtLinkPorts: + description: > + Information about external VNF link ports that were + affected during the lifecycle operation. See note 1. + type: array + items: + description: "This type provides information about added and deleted external link ports (link ports attached to external virtual links).\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to assist in correlating \n the resource changes performed during the LCM operation with the granted resources in a specific Grant exchange, which \n is identified by the \"grantId\" available in the \"Individual VNF lifecycle management operation occurrence\" and the \"id\" \n in the \"Individual Grant\".\n" + type: object + required: + - id + - changeType + - extCpInstanceId + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: "Signals the type of change. Permitted values: -\tADDED - MODIFIED -\tREMOVED\n" + type: string + enum: + - ADDED + - MODIFIED + - REMOVED + extCpInstanceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + resourceDefinitionId: + description: > + An identifier that is unique within a limited + local scope other than above listed identifiers, + such as within a complex data structure or within + a request-response pair. Representation: string of + variable length. + type: string + affectedVirtualStorages: + description: > + Information about virtualised storage instances that + were affected during the lifecycle operation. See note + 1. + type: array + items: + description: "This type provides information about added, deleted, modified and temporary virtual storage resources.\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to \n assist in correlating the resource changes performed during the LCM operation with the granted \n resources in a specific Grant exchange, which is identified by the \"grantId\" available in the \n \"Individual VNF lifecycle management operation occurrence\" and the \"id\" in the \"Individual Grant\".\n" + type: object + required: + - id + - virtualStorageDescId + - changeType + - storageResource + properties: + id: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: > + Signals the type of change. Permitted values: * + ADDED * REMOVED * MODIFIED * TEMPORARY For a + temporary resource, an AffectedVirtualStorage + structure exists as long as the temporary resource + exists. + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + resourceDefinitionId: + description: > + An identifier that is unique within a limited + local scope other than above listed identifiers, + such as within a complex data structure or within + a request-response pair. Representation: string of + variable length. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + changedInfo: + description: "This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource. The attributes that can be included consist of those requested to be modified explicitly in the \"VnfInfoModificationRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly e.g. when modifying the referenced VNF package.\nNOTE:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) \n was modified implicitly following a request to modify the \"vnfdId\" attribute, by \n copying the value of this attribute from the VNFD in the VNF Package identified by \n the \"vnfdId\" attribute.\n" + type: object + properties: + vnfInstanceName: + description: | + A string defined in IETF RFC 8259. + type: string + vnfInstanceDescription: + description: | + A string defined in IETF RFC 8259. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + vimConnectionInfo: + description: > + If present, this attribute signals modifications the + "vimConnectionInfo" attribute array in "VnfInstance". + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute + determines the structure of the "interfaceInfo" + and "accessInfo" attributes, based on the type of + the VIM., CISM, CIR or MCIOP repository. The set + of permitted values is expected to change over + time as new types or versions of VIMs become + available. The ETSI NFV registry of VIM-related + information provides access to information about + VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The structure + of the registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProvider: + description: | + A string defined in IETF RFC 8259. + type: string + vnfProductName: + description: | + A string defined in IETF RFC 8259. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + affectedVipCps: + description: > + Information about virtual IP CP instances that were affected + during the execution of the lifecycle management operation. + type: array + items: + description: > + This type provides information about added, deleted and + modified virtual IP CP instances. + type: object + required: + - cpInstanceId + - cpdId + - changeType + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: "Signals the type of change. Permitted values: -\tADDED -\tREMOVED -\tMODIFIED\n" + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + changedExtConnectivity: + description: > + Information about changed external connectivity, if + applicable. See note 1. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the CISM + and shall be absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used + by a VNF instance. Information about the + resource is available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See + note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the + VIM or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall + be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the current CP + configuration information for the connection of + external CPs to the external virtual link. See note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured + on the CP instances created from the respective + CPD. + + The key of the map which identifies the + individual VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. + + The entries shall be applied by the VNFM + according to the rules of JSON Merge Patch (see + IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case + of deleting an external CP, the list of + instances to be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided + link port, or a network attachment definition + resource of secondary container cluster + network, or network address information per + instance of an external connection point. In + the case of VM-based deployment of the VNFC + exposing the external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of + the VNFC exposing the external CP, the VNFM + shall use the network attachment definition + resource of secondary container cluster + network when connecting the CP to the external + VL. + + * NOTE 1: The following conditions apply to + the attributes "linkPortId" and + "cpProtocolData" for an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to + the attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. + If set to True, the VNFM shall create a + link port. If set to False, the VNFM shall + not create a link port. This attribute is + only applicable for external CP instances + without a floating IP address that expose + a VIP CP instance for which a dedicated IP + address is allocated. It shall be present + in that case and shall be absent + otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification + of the interface to attach the external CP + to a secondary container cluster network. + It is only applicable if the external CP + is connected or to be connected to a + secondary container cluster network. It + shall not be present if the external CP is + related to a virtual network not + categorized as secondary container cluster + network. See notes 2, 3 and 4. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects + the CP to a VL and the domain names for + the external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD + is activated/deactivated and for an + activated security group rule the values + of attributes defined in the VNFD that can + be overriden such as "portRangeMin" and + "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extNetAttDefResource: + description: > + Network attachment definition resources that provide + the specification of the interface to attach + connection points to this VL. + type: array + items: + description: > + This type contains information related to a network + attachment definition resource that provides the + specification of the interface used to connect one + or multiple connection points to a secondary + container cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of being + globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used + by a VNF instance. Information about the + resource is available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See + note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the + VIM or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall + be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated to this + network attachment definition resource. Shall be + present when the network attachment definition + resource is used for external connectivity by + the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to this + network attachment definition resource. May be + present when the network attachment definition + resource is used for internal connectivity by + the VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been configured + (statically or dynamically) and been associated to the + CP. + type: array + items: + type: string + modificationsTriggeredByVnfPkgChange: + description: "This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource when changing the current VNF package. The attributes that can be included consist of those requested to be modified explicitly in the \"ChangeCurrentVnfPkgRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly during the operation.\nNOTE 1:\tThis attribute represents the delta (semantics as per IETF RFC 7396, JSON Merge Patch) between the value \n of the attribute at the start of the \"Change current VNF package\" operation and the value of the attribute \n at its completion.\nNOTE 2:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) was modified implicitly \n during the related operation and contains a copy of the value of the related attribute from the VNFD in the \n VNF Package identified by the \"vnfdId\" attribute.\n" + type: object + properties: + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProvider: + description: > + If present, this attribute signals the new value of the + "vnfProvider" attribute in "VnfInstance". See note 2. + type: string + vnfProductName: + description: > + If present, this attribute signals the new value of the + "vnfProductName" attribute in "VnfInstance". See note 2. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vimConnectionInfo: + description: > + If present, this attribute signals the changes to VIM + connection info that were passed in the related + "ChangeCurrentVnfPkgRequest" structure. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute + determines the structure of the "interfaceInfo" + and "accessInfo" attributes, based on the type of + the VIM., CISM, CIR or MCIOP repository. The set + of permitted values is expected to change over + time as new types or versions of VIMs become + available. The ETSI NFV registry of VIM-related + information provides access to information about + VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The structure + of the registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + vnfSnapshotInfoId: + description: | + An identifier with the intention of being globally unique. + type: string + lcmCoordinations: + description: > + Information about LCM coordination actions (see clause 10 in + ETSI GS NFV-SOL002) related to this LCM operation + occurrence. + type: array + items: + type: object + required: + - id + - coordinationActionName + - startTime + - endpointType + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + coordinationActionName: + description: > + An identifier with the intention of being globally + unique. + type: string + coordinationResult: + description: > + The enumeration LcmCoordResultType defines the + permitted values to represent the result of executing + an LCM coordination action. The coordination result + also implies the action to be performed by the VNFM as + the follow-up to this coordination. Value | + Description ------|------------ CONTINUE | The related + LCM operation shall be continued, staying in the state + "PROCESSING". ABORT | The related LCM operation shall + be aborted by transitioning into the state + "FAILED_TEMP". CANCELLED | The coordination action has + been cancelled upon request of the API consumer, i.e. + the VNFM. The related LCM operation shall be aborted + by transitioning into the state "FAILED_TEMP". + type: string + enum: + - CONTINUE + - ABORT + - CANCELLED + startTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + endTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + delay: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + endpointType: + description: "The endpoint type used by this coordination action. Valid values: •\tMGMT: coordination with other operation supporting management systems (e.g. EM) •\tVNF: coordination with the VNF instance\n" + type: string + enum: + - MGMT + - VNF + rejectedLcmCoordinations: + description: > + Information about LCM coordination actions (see clause 10 in + ETSI GS NFV-SOL002) that were rejected by 503 error which + means they can be tried again after a delay. See note 5. + type: array + items: + type: object + required: + - coordinationActionName + - rejectionTime + - endpointType + - delay + properties: + coordinationActionName: + description: > + An identifier with the intention of being globally + unique. + type: string + rejectionTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + delay: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + endpointType: + description: "The endpoint type used by this coordination action. Valid values: •\tMGMT: coordination with other operation supporting management systems (e.g. EM) •\tVNF: coordination with the VNF instance\n" + type: string + enum: + - MGMT + - VNF + warnings: + description: > + Warning messages that were generated while the operation was + executing. + + If the operation has included LCM coordination actions and + these have resulted in warnings, such warnings should be + added to this attribute. + type: array + items: + type: string + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + - vnfInstance + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + grant: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + cancel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + retry: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + rollback: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + fail: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualVnfLcmOpOcc.Get.200: + description: > + 200 OK + + + Shall be returned when information about a VNF LCM operation occurrence + washas been read successfully. + + The response body shall contain status information about a VNF lifecycle + management operation occurrence + + (see clause 5.5.2.13). + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: "This type represents a VNF lifecycle management operation occurrence.\nNOTE 1:\tThis allows the NFVO to obtain the information contained in the latest \n \"result\" notification if it has not received it due to an error or a \n wrongly configured subscription filter.\nNOTE 2:\tNot more than one of changedInfo and modificationsTriggeredByVnfPkgChange \n shall be present.\nNOTE 3:\tFor a particular affected VL, there shall be as many \"AffectedVirtualLink\" \n entries as needed for signalling the different types of changes, i.e. one \n per virtual link and change type. For instance, in the case of signaling \n affected VL instances involving the addition of a particular VL instance \n with links ports, one \"AffectedVirtualLink\" entry signals the addition of \n the VL by using the \"changeType\" attribute of \"AffectedVirtualLink\" structure \n equal to \"ADDED\", and another \"AffectedVirtualLink\" entry signals the addition \n of externally visible VNF link ports of the VL by using the \"changeType\" equal \n to \"LINK_PORT_ADDED\".\nNOTE 4:\tA coordination action has timed out if the VNFM has not been able to read the \n \"Individual coordination action\" resource within a timeout interval after requesting \n the coordination to be started or to be cancelled. The length of the timeout interval \n is defined by means outside the scope of the present document.\nNOTE 5: The list of rejected coordinations may be garbage collected if the LCM operation\n occurrence has reached a terminal state, i.e. one of \"COMPLETED\", \"FAILED\" and \"ROLLED_BACK\".\n" + type: object + oneOf: + - required: + - changedInfo + - required: + - modificationsTriggeredByVnfPkgChange + required: + - id + - operationState + - stateEnteredTime + - startTime + - vnfInstanceId + - operation + - isAutomaticInvocation + - isCancelPending + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + operationState: + description: > + STARTING: The LCM operation is starting. PROCESSING: The LCM + operation is currently in execution. COMPLETED: The LCM + operation has been completed successfully. FAILED_TEMP: The + LCM operation has failed and execution has stopped, but the + execution of the operation is not considered to be closed. + FAILED: The LCM operation has failed and it cannot be retried + or rolled back, as it is determined that such action won't + succeed. ROLLING_BACK: The LCM operation is currently being + rolled back. ROLLED_BACK: The LCM operation has been + successfully rolled back, i.e. The state of the VNF prior to + the original operation invocation has been restored as closely + as possible. + type: string + enum: + - STARTING + - PROCESSING + - COMPLETED + - FAILED_TEMP + - FAILED + - ROLLING_BACK + - ROLLED_BACK + stateEnteredTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + startTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + grantId: + description: | + An identifier with the intention of being globally unique. + type: string + operation: + description: > + The enumeration LcmOpType defines the permitted values to + represent VNF lifecycle operation types in VNF lifecycle + management operation occurrence resources and VNF lifecycle + management operation occurrence notifications. + + Value | Description ------|------------ INSTANTIATE | + Represents the "Instantiate VNF" LCM operation. SCALE | + Represents the "Scale VNF" LCM operation. SCALE_TO_LEVEL | + Represents the "Scale VNF to Level" LCM operation. + CHANGE_FLAVOUR | Represents the "Change VNF Flavour" LCM + operation. TERMINATE | Represents the "Terminate VNF" LCM + operation. HEAL | Represents the "Heal VNF" LCM operation. + OPERATE | Represents the "Operate VNF" LCM operation. + CHANGE_EXT_CONN | Represents the "Change external VNF + connectivity" LCM operation. MODIFY_INFO | Represents the + "Modify VNF Information" LCM operation. CREATE_SNAPSHOT | + Represents the "Create VNF Snapshot" LCM operation. + REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot" + LCM operation. CHANGE_VNFPKG | Represents the "Change current + VNF package" LCM operation. SELECT_DEPL_MODS | Represents the + “Select VNF deployable modules” LCM operation + type: string + enum: + - INSTANTIATE + - SCALE + - SCALE_TO_LEVEL + - CHANGE_FLAVOUR + - TERMINATE + - HEAL + - OPERATE + - CHANGE_EXT_CONN + - MODIFY_INFO + - CREATE_SNAPSHOT + - REVERT_TO_SNAPSHOT + - CHANGE_VNFPKG + - SELECT_DEPL_MODS + isAutomaticInvocation: + description: | + The Boolean is a data type having two values (true and false). + type: boolean + operationParams: + description: > + Input parameters of the LCM operation. This attribute shall be + formatted according to the request data type of the related + LCM operation. In addition, the provisions in clause 5.7 shall + apply. + + The following mapping between operationType and the data type + of this attribute shall apply: * INSTANTIATE: + InstantiateVnfRequest * SCALE: ScaleVnfRequest * + SCALE_TO_LEVEL: ScaleVnfToLevelRequest * CHANGE_FLAVOUR: + ChangeVnfFlavourRequest * OPERATE: OperateVnfRequest * HEAL: + HealVnfRequest * CHANGE_EXT_CONN: + ChangeExtVnfConnectivityRequest * TERMINATE: + TerminateVnfRequest * MODIFY_INFO: VnfInfoModifications * + CREATE_SNAPSHOT: CreateVnfSnapshotRequest * + REVERT_TO_SNAPSHOT: RevertToVnfSnapshotRequest * + CHANGE_VNFPKG: ChangeCurrentVnfPkgRequest * SELECT_DEPL_MODS: + SelectVnfDeployableModulesRequest + type: object + isCancelPending: + description: | + The Boolean is a data type having two values (true and false). + type: boolean + cancelMode: + description: > + Cancellation mode. GRACEFUL: If the VNF LCM operation + occurrence is in "PROCESSING" or "ROLLING_BACK" state, the + VNFM shall not start any new resource management operation and + shall wait for the ongoing resource management operations in + the underlying system, typically the VIM, to finish execution + or to time out. After that, the VNFM shall put the operation + occurrence into the FAILED_TEMP state. If the VNF LCM + operation occurrence is in "STARTING" state, the VNFM shall + not start any resource management operation and shall wait for + the granting request to finish execution or time out. After + that, the VNFM shall put the operation occurrence into the + ROLLED_BACK state. FORCEFUL: If the VNF LCM operation + occurrence is in "PROCESSING" or "ROLLING_BACK" state, the + VNFM shall not start any new resource management operation, + shall cancel the ongoing resource management operations in the + underlying system, typically the VIM, and shall wait for the + cancellation to finish or to time out. After that, the VNFM + shall put the operation occurrence into the FAILED_TEMP state. + If the VNF LCM operation occurrence is in "STARTING" state, + the VNFM shall not start any resource management operation and + put the operation occurrence into the ROLLED_BACK state. + type: string + enum: + - GRACEFUL + - FORCEFUL + error: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + resourceChanges: + description: > + This attribute contains information about the cumulative + changes to virtualised resources that were performed so far by + the LCM operation since its start, if applicable. + type: object + properties: + affectedVnfcs: + description: > + Information about VNFC instances that were affected during + the lifecycle operation. See note 1. + type: array + items: + description: "This type provides information about added, deleted, modified and temporary VNFCs.\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer \n (i.e. the NFVO) to assist in correlating the resource changes performed during \n the LCM operation with the granted resources in a specific Grant exchange, which \n is identified by the \"grantId\" available in the \"Individual VNF lifecycle management \n operation occurrence\" and the \"id\" in the \"Individual Grant\".\n" + type: object + required: + - id + - vduId + - changeType + - computeResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: > + Signals the type of change. Permitted values: * + ADDED * REMOVED * MODIFIED * TEMPORARY For a + temporary resource, an AffectedVnfc structure exists + as long as the temporary resource exists. + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + resourceDefinitionId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + affectedVnfcCpIds: + description: > + Identifiers of CP(s) of the VNFC instance that were + affected by the change. Shall be present for those + affected CPs of the VNFC instance that are + associated to an external CP of the VNF instance. + May be present for further affected CPs of the VNFC + instance. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + addedStorageResourceIds: + description: > + References to VirtualStorage resources that have + been added. Each value refers to a + VirtualStorageResourceInfo item in the VnfInstance + that was added to the VNFC. It shall be provided if + at least one storage resource was added to the VNFC. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + removedStorageResourceIds: + description: > + References to VirtualStorage resources that have + been removed. The value contains the identifier of a + VirtualStorageResourceInfo item that has been + removed from the VNFC, and might no longer exist in + the VnfInstance. It shall be provided if at least + one storage resource was removed from the VNFC. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + affectedVirtualLinks: + description: > + Information about VL instances that were affected during + the lifecycle operation. See notes 1 and 3. + type: array + items: + description: "This type provides information about added, deleted, modified and temporary VLs, and added or removed VNF link ports.\nNOTE 1:\tWhen signalling the addition (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) of VNF link ports, \n the \"networkResource\" and \"resourceDefinitionId\" attributes refer to the affected virtual link \n instance, not the link port instance. The resource handles of the affected VNF link ports can be \n found by dereferencing the identifiers in the \"vnfLinkPortIds\" attribute.\nNOTE 2:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to \n assist in correlating the resource changes performed during the LCM operation with the granted \n resources in a specific Grant exchange, which is identified by the \"grantId\" available in the \n \"Individual VNF lifecycle management operation occurrence\" and the \"id\" in the \"Individual Grant\".\n" + type: object + required: + - id + - vnfVirtualLinkDescId + - changeType + - networkResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: "Signals the type of change.\nPermitted values: -\tADDED -\tREMOVED -\tMODIFIED -\tTEMPORARY -\tLINK_PORT_ADDED -\tLINK_PORT_REMOVED For a temporary resource, an AffectedVirtualLink structure exists as long as the temporary resource exists. See note 1.\n" + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + - LINK_PORT_ADDED + - LINK_PORT_REMOVED + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + vnfLinkPortIds: + description: > + Identifiers of the link ports of the affected VL + related to the change. Each identifier references a + "VnfLinkPortInfo" structure. + + Shall be set when changeType is equal to + "LINK_PORT_ADDED" or "LINK_PORT_REMOVED", and the + related "VnfLinkPortInfo" structures are present + (case "added") or have been present (case "removed") + in the "VnfVirtualLinkResourceInfo" or + "ExtManagedVirtualLinkInfo" structures that are + represented by the "vnfVirtualLinkResource¬Info" or + "extManagedVirtualLinkInfo" attribute in the + "VnfInstance" structure. See note 1. + type: array + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + resourceDefinitionId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + affectedExtLinkPorts: + description: > + Information about external VNF link ports that were + affected during the lifecycle operation. See note 1. + type: array + items: + description: "This type provides information about added and deleted external link ports (link ports attached to external virtual links).\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to assist in correlating \n the resource changes performed during the LCM operation with the granted resources in a specific Grant exchange, which \n is identified by the \"grantId\" available in the \"Individual VNF lifecycle management operation occurrence\" and the \"id\" \n in the \"Individual Grant\".\n" + type: object + required: + - id + - changeType + - extCpInstanceId + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: "Signals the type of change. Permitted values: -\tADDED - MODIFIED -\tREMOVED\n" + type: string + enum: + - ADDED + - MODIFIED + - REMOVED + extCpInstanceId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + resourceDefinitionId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + affectedVirtualStorages: + description: > + Information about virtualised storage instances that were + affected during the lifecycle operation. See note 1. + type: array + items: + description: "This type provides information about added, deleted, modified and temporary virtual storage resources.\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to \n assist in correlating the resource changes performed during the LCM operation with the granted \n resources in a specific Grant exchange, which is identified by the \"grantId\" available in the \n \"Individual VNF lifecycle management operation occurrence\" and the \"id\" in the \"Individual Grant\".\n" + type: object + required: + - id + - virtualStorageDescId + - changeType + - storageResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: > + Signals the type of change. Permitted values: * + ADDED * REMOVED * MODIFIED * TEMPORARY For a + temporary resource, an AffectedVirtualStorage + structure exists as long as the temporary resource + exists. + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + resourceDefinitionId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + changedInfo: + description: "This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource. The attributes that can be included consist of those requested to be modified explicitly in the \"VnfInfoModificationRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly e.g. when modifying the referenced VNF package.\nNOTE:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) \n was modified implicitly following a request to modify the \"vnfdId\" attribute, by \n copying the value of this attribute from the VNFD in the VNF Package identified by \n the \"vnfdId\" attribute.\n" + type: object + properties: + vnfInstanceName: + description: | + A string defined in IETF RFC 8259. + type: string + vnfInstanceDescription: + description: | + A string defined in IETF RFC 8259. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + vimConnectionInfo: + description: > + If present, this attribute signals modifications the + "vimConnectionInfo" attribute array in "VnfInstance". + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines + the structure of the "interfaceInfo" and + "accessInfo" attributes, based on the type of the + VIM., CISM, CIR or MCIOP repository. The set of + permitted values is expected to change over time as + new types or versions of VIMs become available. The + ETSI NFV registry of VIM-related information + provides access to information about + VimConnectionInfo definitions for various VIM, CISM, + CIR or MCIOP repository types. The structure of the + registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfProvider: + description: | + A string defined in IETF RFC 8259. + type: string + vnfProductName: + description: | + A string defined in IETF RFC 8259. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + affectedVipCps: + description: > + Information about virtual IP CP instances that were affected + during the execution of the lifecycle management operation. + type: array + items: + description: > + This type provides information about added, deleted and + modified virtual IP CP instances. + type: object + required: + - cpInstanceId + - cpdId + - changeType + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: "Signals the type of change. Permitted values: -\tADDED -\tREMOVED -\tMODIFIED\n" + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + changedExtConnectivity: + description: > + Information about changed external connectivity, if + applicable. See note 1. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the current CP + configuration information for the connection of external + CPs to the external virtual link. See note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. + + The entries shall be applied by the VNFM according + to the rules of JSON Merge Patch (see IETF RFC + 7396). See notes 2, 3, 4, 5, 6. In case of + deleting an external CP, the list of instances to + be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extNetAttDefResource: + description: > + Network attachment definition resources that provide the + specification of the interface to attach connection + points to this VL. + type: array + items: + description: > + This type contains information related to a network + attachment definition resource that provides the + specification of the interface used to connect one or + multiple connection points to a secondary container + cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of being globally + unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated to this + network attachment definition resource. Shall be + present when the network attachment definition + resource is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to this + network attachment definition resource. May be + present when the network attachment definition + resource is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been configured + (statically or dynamically) and been associated to the + CP. + type: array + items: + type: string + modificationsTriggeredByVnfPkgChange: + description: "This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource when changing the current VNF package. The attributes that can be included consist of those requested to be modified explicitly in the \"ChangeCurrentVnfPkgRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly during the operation.\nNOTE 1:\tThis attribute represents the delta (semantics as per IETF RFC 7396, JSON Merge Patch) between the value \n of the attribute at the start of the \"Change current VNF package\" operation and the value of the attribute \n at its completion.\nNOTE 2:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) was modified implicitly \n during the related operation and contains a copy of the value of the related attribute from the VNFD in the \n VNF Package identified by the \"vnfdId\" attribute.\n" + type: object + properties: + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfProvider: + description: > + If present, this attribute signals the new value of the + "vnfProvider" attribute in "VnfInstance". See note 2. + type: string + vnfProductName: + description: > + If present, this attribute signals the new value of the + "vnfProductName" attribute in "VnfInstance". See note 2. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vimConnectionInfo: + description: > + If present, this attribute signals the changes to VIM + connection info that were passed in the related + "ChangeCurrentVnfPkgRequest" structure. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines + the structure of the "interfaceInfo" and + "accessInfo" attributes, based on the type of the + VIM., CISM, CIR or MCIOP repository. The set of + permitted values is expected to change over time as + new types or versions of VIMs become available. The + ETSI NFV registry of VIM-related information + provides access to information about + VimConnectionInfo definitions for various VIM, CISM, + CIR or MCIOP repository types. The structure of the + registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + vnfSnapshotInfoId: + description: | + An identifier with the intention of being globally unique. + type: string + lcmCoordinations: + description: > + Information about LCM coordination actions (see clause 10 in + ETSI GS NFV-SOL002) related to this LCM operation occurrence. + type: array + items: + type: object + required: + - id + - coordinationActionName + - startTime + - endpointType + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + coordinationActionName: + description: > + An identifier with the intention of being globally + unique. + type: string + coordinationResult: + description: > + The enumeration LcmCoordResultType defines the permitted + values to represent the result of executing an LCM + coordination action. The coordination result also + implies the action to be performed by the VNFM as the + follow-up to this coordination. Value | Description + ------|------------ CONTINUE | The related LCM operation + shall be continued, staying in the state "PROCESSING". + ABORT | The related LCM operation shall be aborted by + transitioning into the state "FAILED_TEMP". CANCELLED | + The coordination action has been cancelled upon request + of the API consumer, i.e. the VNFM. The related LCM + operation shall be aborted by transitioning into the + state "FAILED_TEMP". + type: string + enum: + - CONTINUE + - ABORT + - CANCELLED + startTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + endTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + delay: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + endpointType: + description: "The endpoint type used by this coordination action. Valid values: •\tMGMT: coordination with other operation supporting management systems (e.g. EM) •\tVNF: coordination with the VNF instance\n" + type: string + enum: + - MGMT + - VNF + rejectedLcmCoordinations: + description: > + Information about LCM coordination actions (see clause 10 in + ETSI GS NFV-SOL002) that were rejected by 503 error which + means they can be tried again after a delay. See note 5. + type: array + items: + type: object + required: + - coordinationActionName + - rejectionTime + - endpointType + - delay + properties: + coordinationActionName: + description: > + An identifier with the intention of being globally + unique. + type: string + rejectionTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + delay: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + endpointType: + description: "The endpoint type used by this coordination action. Valid values: •\tMGMT: coordination with other operation supporting management systems (e.g. EM) •\tVNF: coordination with the VNF instance\n" + type: string + enum: + - MGMT + - VNF + warnings: + description: > + Warning messages that were generated while the operation was + executing. + + If the operation has included LCM coordination actions and + these have resulted in warnings, such warnings should be added + to this attribute. + type: array + items: + type: string + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + - vnfInstance + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + grant: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + cancel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + retry: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + rollback: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + fail: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + RollbackVnfLcmOpOcc.Post.202: + description: | + 202 ACCEPTED + + Shall be returned when the request has been accepted for processing. + The response shall have an empty message content. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + RollbackVnfLcmOpOcc.Post.404: + description: | + 404 NOT FOUND + + Shall be returned upon the following error: The API + producer did not find a current representation for the + target resource or is not willing to disclose that one + exists. + The general cause for this error and its handling is + specified in clause 6.4 of ETSI GS NFV-SOL 013 [8], + including rules for the presence of the response body. + Specifically in case of this task resource, the response + code 404 shall also be returned if the task is not + supported for the VNF LCM operation occurrence + represented by the parent resource, which means that + the task resource consequently does not exist. + In this case, the response body shall be present, and + shall contain a ProblemDetails structure, in which the + "detail" attribute shall convey more information about + the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + RollbackVnfLcmOpOcc.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the VNF LCM operation + occurrence. + Typically, this is due to the fact that the VNF LCM + operation occurrence is not in FAILED_TEMP state, or + another error handling action is starting, such as retry + or fail. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + RetryVnfLcmOpOcc.Post.202: + description: | + 202 ACCEPTED + + Shall be returned when the request has been accepted for processing. + The response shall have an empty message content. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + RetryVnfLcmOpOcc.Post.404: + description: | + 404 NOT FOUND + + Shall be returned upon the following error: The API + producer did not find a current representation for the + target resource or is not willing to disclose that one + exists. + The general cause for this error and its handling is + specified in clause 6.4 of ETSI GS NFV-SOL 013 [8], + including rules for the presence of the response body. + Specifically in case of this task resource, the response + code 404 shall also be returned if the task is not + supported for the VNF LCM operation occurrence + represented by the parent resource, which means that + the task resource consequently does not exist. + In this case, the response body shall be present, and + shall contain a ProblemDetails structure, in which the + "detail" attribute shall convey more information about + the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + RetryVnfLcmOpOcc.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the VNF LCM operation + occurrence. + Typically, this is due to the fact that the VNF LCM + operation occurrence is not in FAILED_TEMP state, or + another error handling action is starting, such as + rollback or fail. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + FailVnfLcmOpOcc.Post.200: + description: > + 200 OK + + + Shall be returned when the state of the VNF lifecycle management + operation occurrence + + has been changed successfully. + + The response body shall include a representation of the "Individual VNF + lifecycle operation occurrence" + + resource. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: "This type represents a VNF lifecycle management operation occurrence.\nNOTE 1:\tThis allows the NFVO to obtain the information contained in the latest \n \"result\" notification if it has not received it due to an error or a \n wrongly configured subscription filter.\nNOTE 2:\tNot more than one of changedInfo and modificationsTriggeredByVnfPkgChange \n shall be present.\nNOTE 3:\tFor a particular affected VL, there shall be as many \"AffectedVirtualLink\" \n entries as needed for signalling the different types of changes, i.e. one \n per virtual link and change type. For instance, in the case of signaling \n affected VL instances involving the addition of a particular VL instance \n with links ports, one \"AffectedVirtualLink\" entry signals the addition of \n the VL by using the \"changeType\" attribute of \"AffectedVirtualLink\" structure \n equal to \"ADDED\", and another \"AffectedVirtualLink\" entry signals the addition \n of externally visible VNF link ports of the VL by using the \"changeType\" equal \n to \"LINK_PORT_ADDED\".\nNOTE 4:\tA coordination action has timed out if the VNFM has not been able to read the \n \"Individual coordination action\" resource within a timeout interval after requesting \n the coordination to be started or to be cancelled. The length of the timeout interval \n is defined by means outside the scope of the present document.\nNOTE 5: The list of rejected coordinations may be garbage collected if the LCM operation\n occurrence has reached a terminal state, i.e. one of \"COMPLETED\", \"FAILED\" and \"ROLLED_BACK\".\n" + type: object + oneOf: + - required: + - changedInfo + - required: + - modificationsTriggeredByVnfPkgChange + required: + - id + - operationState + - stateEnteredTime + - startTime + - vnfInstanceId + - operation + - isAutomaticInvocation + - isCancelPending + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + operationState: + description: > + STARTING: The LCM operation is starting. PROCESSING: The LCM + operation is currently in execution. COMPLETED: The LCM + operation has been completed successfully. FAILED_TEMP: The + LCM operation has failed and execution has stopped, but the + execution of the operation is not considered to be closed. + FAILED: The LCM operation has failed and it cannot be retried + or rolled back, as it is determined that such action won't + succeed. ROLLING_BACK: The LCM operation is currently being + rolled back. ROLLED_BACK: The LCM operation has been + successfully rolled back, i.e. The state of the VNF prior to + the original operation invocation has been restored as closely + as possible. + type: string + enum: + - STARTING + - PROCESSING + - COMPLETED + - FAILED_TEMP + - FAILED + - ROLLING_BACK + - ROLLED_BACK + stateEnteredTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + startTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + grantId: + description: | + An identifier with the intention of being globally unique. + type: string + operation: + description: > + The enumeration LcmOpType defines the permitted values to + represent VNF lifecycle operation types in VNF lifecycle + management operation occurrence resources and VNF lifecycle + management operation occurrence notifications. + + Value | Description ------|------------ INSTANTIATE | + Represents the "Instantiate VNF" LCM operation. SCALE | + Represents the "Scale VNF" LCM operation. SCALE_TO_LEVEL | + Represents the "Scale VNF to Level" LCM operation. + CHANGE_FLAVOUR | Represents the "Change VNF Flavour" LCM + operation. TERMINATE | Represents the "Terminate VNF" LCM + operation. HEAL | Represents the "Heal VNF" LCM operation. + OPERATE | Represents the "Operate VNF" LCM operation. + CHANGE_EXT_CONN | Represents the "Change external VNF + connectivity" LCM operation. MODIFY_INFO | Represents the + "Modify VNF Information" LCM operation. CREATE_SNAPSHOT | + Represents the "Create VNF Snapshot" LCM operation. + REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot" + LCM operation. CHANGE_VNFPKG | Represents the "Change current + VNF package" LCM operation. SELECT_DEPL_MODS | Represents the + “Select VNF deployable modules” LCM operation + type: string + enum: + - INSTANTIATE + - SCALE + - SCALE_TO_LEVEL + - CHANGE_FLAVOUR + - TERMINATE + - HEAL + - OPERATE + - CHANGE_EXT_CONN + - MODIFY_INFO + - CREATE_SNAPSHOT + - REVERT_TO_SNAPSHOT + - CHANGE_VNFPKG + - SELECT_DEPL_MODS + isAutomaticInvocation: + description: | + The Boolean is a data type having two values (true and false). + type: boolean + operationParams: + description: > + Input parameters of the LCM operation. This attribute shall be + formatted according to the request data type of the related + LCM operation. In addition, the provisions in clause 5.7 shall + apply. + + The following mapping between operationType and the data type + of this attribute shall apply: * INSTANTIATE: + InstantiateVnfRequest * SCALE: ScaleVnfRequest * + SCALE_TO_LEVEL: ScaleVnfToLevelRequest * CHANGE_FLAVOUR: + ChangeVnfFlavourRequest * OPERATE: OperateVnfRequest * HEAL: + HealVnfRequest * CHANGE_EXT_CONN: + ChangeExtVnfConnectivityRequest * TERMINATE: + TerminateVnfRequest * MODIFY_INFO: VnfInfoModifications * + CREATE_SNAPSHOT: CreateVnfSnapshotRequest * + REVERT_TO_SNAPSHOT: RevertToVnfSnapshotRequest * + CHANGE_VNFPKG: ChangeCurrentVnfPkgRequest * SELECT_DEPL_MODS: + SelectVnfDeployableModulesRequest + type: object + isCancelPending: + description: | + The Boolean is a data type having two values (true and false). + type: boolean + cancelMode: + description: > + Cancellation mode. GRACEFUL: If the VNF LCM operation + occurrence is in "PROCESSING" or "ROLLING_BACK" state, the + VNFM shall not start any new resource management operation and + shall wait for the ongoing resource management operations in + the underlying system, typically the VIM, to finish execution + or to time out. After that, the VNFM shall put the operation + occurrence into the FAILED_TEMP state. If the VNF LCM + operation occurrence is in "STARTING" state, the VNFM shall + not start any resource management operation and shall wait for + the granting request to finish execution or time out. After + that, the VNFM shall put the operation occurrence into the + ROLLED_BACK state. FORCEFUL: If the VNF LCM operation + occurrence is in "PROCESSING" or "ROLLING_BACK" state, the + VNFM shall not start any new resource management operation, + shall cancel the ongoing resource management operations in the + underlying system, typically the VIM, and shall wait for the + cancellation to finish or to time out. After that, the VNFM + shall put the operation occurrence into the FAILED_TEMP state. + If the VNF LCM operation occurrence is in "STARTING" state, + the VNFM shall not start any resource management operation and + put the operation occurrence into the ROLLED_BACK state. + type: string + enum: + - GRACEFUL + - FORCEFUL + error: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + resourceChanges: + description: > + This attribute contains information about the cumulative + changes to virtualised resources that were performed so far by + the LCM operation since its start, if applicable. + type: object + properties: + affectedVnfcs: + description: > + Information about VNFC instances that were affected during + the lifecycle operation. See note 1. + type: array + items: + description: "This type provides information about added, deleted, modified and temporary VNFCs.\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer \n (i.e. the NFVO) to assist in correlating the resource changes performed during \n the LCM operation with the granted resources in a specific Grant exchange, which \n is identified by the \"grantId\" available in the \"Individual VNF lifecycle management \n operation occurrence\" and the \"id\" in the \"Individual Grant\".\n" + type: object + required: + - id + - vduId + - changeType + - computeResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: > + Signals the type of change. Permitted values: * + ADDED * REMOVED * MODIFIED * TEMPORARY For a + temporary resource, an AffectedVnfc structure exists + as long as the temporary resource exists. + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + resourceDefinitionId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + affectedVnfcCpIds: + description: > + Identifiers of CP(s) of the VNFC instance that were + affected by the change. Shall be present for those + affected CPs of the VNFC instance that are + associated to an external CP of the VNF instance. + May be present for further affected CPs of the VNFC + instance. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + addedStorageResourceIds: + description: > + References to VirtualStorage resources that have + been added. Each value refers to a + VirtualStorageResourceInfo item in the VnfInstance + that was added to the VNFC. It shall be provided if + at least one storage resource was added to the VNFC. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + removedStorageResourceIds: + description: > + References to VirtualStorage resources that have + been removed. The value contains the identifier of a + VirtualStorageResourceInfo item that has been + removed from the VNFC, and might no longer exist in + the VnfInstance. It shall be provided if at least + one storage resource was removed from the VNFC. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + affectedVirtualLinks: + description: > + Information about VL instances that were affected during + the lifecycle operation. See notes 1 and 3. + type: array + items: + description: "This type provides information about added, deleted, modified and temporary VLs, and added or removed VNF link ports.\nNOTE 1:\tWhen signalling the addition (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) of VNF link ports, \n the \"networkResource\" and \"resourceDefinitionId\" attributes refer to the affected virtual link \n instance, not the link port instance. The resource handles of the affected VNF link ports can be \n found by dereferencing the identifiers in the \"vnfLinkPortIds\" attribute.\nNOTE 2:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to \n assist in correlating the resource changes performed during the LCM operation with the granted \n resources in a specific Grant exchange, which is identified by the \"grantId\" available in the \n \"Individual VNF lifecycle management operation occurrence\" and the \"id\" in the \"Individual Grant\".\n" + type: object + required: + - id + - vnfVirtualLinkDescId + - changeType + - networkResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: "Signals the type of change.\nPermitted values: -\tADDED -\tREMOVED -\tMODIFIED -\tTEMPORARY -\tLINK_PORT_ADDED -\tLINK_PORT_REMOVED For a temporary resource, an AffectedVirtualLink structure exists as long as the temporary resource exists. See note 1.\n" + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + - LINK_PORT_ADDED + - LINK_PORT_REMOVED + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + vnfLinkPortIds: + description: > + Identifiers of the link ports of the affected VL + related to the change. Each identifier references a + "VnfLinkPortInfo" structure. + + Shall be set when changeType is equal to + "LINK_PORT_ADDED" or "LINK_PORT_REMOVED", and the + related "VnfLinkPortInfo" structures are present + (case "added") or have been present (case "removed") + in the "VnfVirtualLinkResourceInfo" or + "ExtManagedVirtualLinkInfo" structures that are + represented by the "vnfVirtualLinkResource¬Info" or + "extManagedVirtualLinkInfo" attribute in the + "VnfInstance" structure. See note 1. + type: array + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + resourceDefinitionId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + affectedExtLinkPorts: + description: > + Information about external VNF link ports that were + affected during the lifecycle operation. See note 1. + type: array + items: + description: "This type provides information about added and deleted external link ports (link ports attached to external virtual links).\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to assist in correlating \n the resource changes performed during the LCM operation with the granted resources in a specific Grant exchange, which \n is identified by the \"grantId\" available in the \"Individual VNF lifecycle management operation occurrence\" and the \"id\" \n in the \"Individual Grant\".\n" + type: object + required: + - id + - changeType + - extCpInstanceId + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: "Signals the type of change. Permitted values: -\tADDED - MODIFIED -\tREMOVED\n" + type: string + enum: + - ADDED + - MODIFIED + - REMOVED + extCpInstanceId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + resourceDefinitionId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + affectedVirtualStorages: + description: > + Information about virtualised storage instances that were + affected during the lifecycle operation. See note 1. + type: array + items: + description: "This type provides information about added, deleted, modified and temporary virtual storage resources.\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to \n assist in correlating the resource changes performed during the LCM operation with the granted \n resources in a specific Grant exchange, which is identified by the \"grantId\" available in the \n \"Individual VNF lifecycle management operation occurrence\" and the \"id\" in the \"Individual Grant\".\n" + type: object + required: + - id + - virtualStorageDescId + - changeType + - storageResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: > + Signals the type of change. Permitted values: * + ADDED * REMOVED * MODIFIED * TEMPORARY For a + temporary resource, an AffectedVirtualStorage + structure exists as long as the temporary resource + exists. + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + resourceDefinitionId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + changedInfo: + description: "This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource. The attributes that can be included consist of those requested to be modified explicitly in the \"VnfInfoModificationRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly e.g. when modifying the referenced VNF package.\nNOTE:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) \n was modified implicitly following a request to modify the \"vnfdId\" attribute, by \n copying the value of this attribute from the VNFD in the VNF Package identified by \n the \"vnfdId\" attribute.\n" + type: object + properties: + vnfInstanceName: + description: | + A string defined in IETF RFC 8259. + type: string + vnfInstanceDescription: + description: | + A string defined in IETF RFC 8259. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + vimConnectionInfo: + description: > + If present, this attribute signals modifications the + "vimConnectionInfo" attribute array in "VnfInstance". + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines + the structure of the "interfaceInfo" and + "accessInfo" attributes, based on the type of the + VIM., CISM, CIR or MCIOP repository. The set of + permitted values is expected to change over time as + new types or versions of VIMs become available. The + ETSI NFV registry of VIM-related information + provides access to information about + VimConnectionInfo definitions for various VIM, CISM, + CIR or MCIOP repository types. The structure of the + registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfProvider: + description: | + A string defined in IETF RFC 8259. + type: string + vnfProductName: + description: | + A string defined in IETF RFC 8259. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + affectedVipCps: + description: > + Information about virtual IP CP instances that were affected + during the execution of the lifecycle management operation. + type: array + items: + description: > + This type provides information about added, deleted and + modified virtual IP CP instances. + type: object + required: + - cpInstanceId + - cpdId + - changeType + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: "Signals the type of change. Permitted values: -\tADDED -\tREMOVED -\tMODIFIED\n" + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + changedExtConnectivity: + description: > + Information about changed external connectivity, if + applicable. See note 1. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the current CP + configuration information for the connection of external + CPs to the external virtual link. See note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. + + The entries shall be applied by the VNFM according + to the rules of JSON Merge Patch (see IETF RFC + 7396). See notes 2, 3, 4, 5, 6. In case of + deleting an external CP, the list of instances to + be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extNetAttDefResource: + description: > + Network attachment definition resources that provide the + specification of the interface to attach connection + points to this VL. + type: array + items: + description: > + This type contains information related to a network + attachment definition resource that provides the + specification of the interface used to connect one or + multiple connection points to a secondary container + cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of being globally + unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated to this + network attachment definition resource. Shall be + present when the network attachment definition + resource is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to this + network attachment definition resource. May be + present when the network attachment definition + resource is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been configured + (statically or dynamically) and been associated to the + CP. + type: array + items: + type: string + modificationsTriggeredByVnfPkgChange: + description: "This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource when changing the current VNF package. The attributes that can be included consist of those requested to be modified explicitly in the \"ChangeCurrentVnfPkgRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly during the operation.\nNOTE 1:\tThis attribute represents the delta (semantics as per IETF RFC 7396, JSON Merge Patch) between the value \n of the attribute at the start of the \"Change current VNF package\" operation and the value of the attribute \n at its completion.\nNOTE 2:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) was modified implicitly \n during the related operation and contains a copy of the value of the related attribute from the VNFD in the \n VNF Package identified by the \"vnfdId\" attribute.\n" + type: object + properties: + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfProvider: + description: > + If present, this attribute signals the new value of the + "vnfProvider" attribute in "VnfInstance". See note 2. + type: string + vnfProductName: + description: > + If present, this attribute signals the new value of the + "vnfProductName" attribute in "VnfInstance". See note 2. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vimConnectionInfo: + description: > + If present, this attribute signals the changes to VIM + connection info that were passed in the related + "ChangeCurrentVnfPkgRequest" structure. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines + the structure of the "interfaceInfo" and + "accessInfo" attributes, based on the type of the + VIM., CISM, CIR or MCIOP repository. The set of + permitted values is expected to change over time as + new types or versions of VIMs become available. The + ETSI NFV registry of VIM-related information + provides access to information about + VimConnectionInfo definitions for various VIM, CISM, + CIR or MCIOP repository types. The structure of the + registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + vnfSnapshotInfoId: + description: | + An identifier with the intention of being globally unique. + type: string + lcmCoordinations: + description: > + Information about LCM coordination actions (see clause 10 in + ETSI GS NFV-SOL002) related to this LCM operation occurrence. + type: array + items: + type: object + required: + - id + - coordinationActionName + - startTime + - endpointType + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + coordinationActionName: + description: > + An identifier with the intention of being globally + unique. + type: string + coordinationResult: + description: > + The enumeration LcmCoordResultType defines the permitted + values to represent the result of executing an LCM + coordination action. The coordination result also + implies the action to be performed by the VNFM as the + follow-up to this coordination. Value | Description + ------|------------ CONTINUE | The related LCM operation + shall be continued, staying in the state "PROCESSING". + ABORT | The related LCM operation shall be aborted by + transitioning into the state "FAILED_TEMP". CANCELLED | + The coordination action has been cancelled upon request + of the API consumer, i.e. the VNFM. The related LCM + operation shall be aborted by transitioning into the + state "FAILED_TEMP". + type: string + enum: + - CONTINUE + - ABORT + - CANCELLED + startTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + endTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + delay: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + endpointType: + description: "The endpoint type used by this coordination action. Valid values: •\tMGMT: coordination with other operation supporting management systems (e.g. EM) •\tVNF: coordination with the VNF instance\n" + type: string + enum: + - MGMT + - VNF + rejectedLcmCoordinations: + description: > + Information about LCM coordination actions (see clause 10 in + ETSI GS NFV-SOL002) that were rejected by 503 error which + means they can be tried again after a delay. See note 5. + type: array + items: + type: object + required: + - coordinationActionName + - rejectionTime + - endpointType + - delay + properties: + coordinationActionName: + description: > + An identifier with the intention of being globally + unique. + type: string + rejectionTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + delay: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + endpointType: + description: "The endpoint type used by this coordination action. Valid values: •\tMGMT: coordination with other operation supporting management systems (e.g. EM) •\tVNF: coordination with the VNF instance\n" + type: string + enum: + - MGMT + - VNF + warnings: + description: > + Warning messages that were generated while the operation was + executing. + + If the operation has included LCM coordination actions and + these have resulted in warnings, such warnings should be added + to this attribute. + type: array + items: + type: string + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + - vnfInstance + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + grant: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + cancel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + retry: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + rollback: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + fail: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + FailVnfLcmOpOcc.Post.404: + description: | + 404 NOT FOUND + + Shall be returned upon the following error: The API + producer did not find a current representation for the + target resource or is not willing to disclose that one + exists. + The general cause for this error and its handling is + specified in clause 6.4 of ETSI GS NFV-SOL 013 [8], + including rules for the presence of the response + body. + Specifically in case of this task resource, the + response code 404 shall also be returned if the task + is not supported for the VNF LCM operation + occurrence represented by the parent resource, + which means that the task resource consequently + does not exist. + In this case, the response body shall be present, and + shall contain a ProblemDetails structure, in which the + "detail" attribute shall convey more information about + the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + FailVnfLcmOpOcc.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the VNF LCM operation + occurrence. + Typically, this is due to the fact that the VNF LCM + operation occurrence is not in FAILED_TEMP state, + or another error handling action is starting, such as + retry or rollback. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + CancelVnfLcmOpOcc.Post.202: + description: | + 202 ACCEPTED + + Shall be returned when the request has been accepted for processing. + The response shall have an empty message content. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + CancelVnfLcmOpOcc.Post.404: + description: | + 404 NOT FOUND + + Shall be returned upon the following error: The API + producer did not find a current representation for the + target resource or is not willing to disclose that one + exists. + The general cause for this error and its handling is + specified in clause 6.4 of ETSI GS NFV-SOL 013 [8], + including rules for the presence of the response + body. + Specifically in case of this task resource, the + response code 404 shall also be returned if the task + is not supported for the VNF LCM operation + occurrence represented by the parent resource, + which means that the task resource consequently + does not exist. + In this case, the response body shall be present, and + shall contain a ProblemDetails structure, in which the + "detail" attribute shall convey more information about + the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + CancelVnfLcmOpOcc.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the VNF LCM operation + occurrence. + Typically, this is due to the fact that the operation + occurrence is not in STARTING, PROCESSING or + ROLLING_BACK state. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + Subscriptions.Post.201: + description: > + 201 CREATED + + + Shall be returned when the subscription has been created successfully. + + The response body shall contain a representation of the created + "Individual subscription" resource. + + The HTTP response shall include a "Location" HTTP header that points to + the created + + "Individual subscription" resource. + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + This type represents a subscription related to notifications about + VNF lifecycle changes. + type: object + required: + - id + - callbackUri + - verbosity + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: "This type represents a subscription filter related to notifications about VNF lifecycle changes.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of \n the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdId + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId values + listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, from + one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tVnfLcmOperationOccurrenceNotification -\tVnfIdentifierCreationNotification -\tVnfIdentifierDeletionNotification See note.\n" + type: array + items: + type: string + enum: + - VnfLcmOperationOccurrenceNotification + - VnfIdentifierCreationNotification + - VnfIdentifierDeletionNotification + operationTypes: + description: > + Match particular VNF lifecycle operation types for the + notification of type + VnfLcmOperationOccurrenceNotification. May be present if + the "notificationTypes" attribute contains the value + "VnfLcmOperationOccurrenceNotification", and shall be + absent otherwise. + type: array + items: + description: > + The enumeration LcmOpType defines the permitted values + to represent VNF lifecycle operation types in VNF + lifecycle management operation occurrence resources and + VNF lifecycle management operation occurrence + notifications. + + Value | Description ------|------------ INSTANTIATE | + Represents the "Instantiate VNF" LCM operation. SCALE + | Represents the "Scale VNF" LCM operation. + SCALE_TO_LEVEL | Represents the "Scale VNF to Level" LCM + operation. CHANGE_FLAVOUR | Represents the "Change VNF + Flavour" LCM operation. TERMINATE | Represents the + "Terminate VNF" LCM operation. HEAL | Represents the + "Heal VNF" LCM operation. OPERATE | Represents the + "Operate VNF" LCM operation. CHANGE_EXT_CONN | + Represents the "Change external VNF connectivity" LCM + operation. MODIFY_INFO | Represents the "Modify VNF + Information" LCM operation. CREATE_SNAPSHOT | Represents + the "Create VNF Snapshot" LCM operation. + REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF + Snapshot" LCM operation. CHANGE_VNFPKG | Represents the + "Change current VNF package" LCM operation. + SELECT_DEPL_MODS | Represents the “Select VNF deployable + modules” LCM operation + type: string + enum: + - INSTANTIATE + - SCALE + - SCALE_TO_LEVEL + - CHANGE_FLAVOUR + - TERMINATE + - HEAL + - OPERATE + - CHANGE_EXT_CONN + - MODIFY_INFO + - CREATE_SNAPSHOT + - REVERT_TO_SNAPSHOT + - CHANGE_VNFPKG + - SELECT_DEPL_MODS + operationStates: + description: > + Match particular LCM operation state values as reported in + notifications of type + VnfLcmOperationOccurrenceNotification. May be present if + the "notificationTypes" attribute contains the value + "VnfLcmOperationOccurrenceNotification", and shall be + absent otherwise. + type: array + items: + description: > + STARTING: The LCM operation is starting. PROCESSING: The + LCM operation is currently in execution. COMPLETED: The + LCM operation has been completed successfully. + FAILED_TEMP: The LCM operation has failed and execution + has stopped, but the execution of the operation is not + considered to be closed. FAILED: The LCM operation has + failed and it cannot be retried or rolled back, as it is + determined that such action won't succeed. ROLLING_BACK: + The LCM operation is currently being rolled back. + ROLLED_BACK: The LCM operation has been successfully + rolled back, i.e. The state of the VNF prior to the + original operation invocation has been restored as + closely as possible. + type: string + enum: + - STARTING + - PROCESSING + - COMPLETED + - FAILED_TEMP + - FAILED + - ROLLING_BACK + - ROLLED_BACK + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + verbosity: + description: > + The enumeration LcmOpOccNotificationVerbosityType provides + values to control the verbosity of LCM operation occurrence + notifications. * FULL: This signals a full notification which + contains all change details. * SHORT: This signals a short + notification which omits large-volume change details to reduce + the size of data to + be sent via the notification mechanism. + type: string + enum: + - FULL + - SHORT + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + Subscriptions.Post.303: + description: | + 303 See Other + + Shall be returned if a subscription with the same + callback URI and the same filter already exists + and the policy of the VNFM is to not create + redundant subscriptions. + The HTTP response shall include a "Location" + HTTP header that contains the resource URI of + the existing "Individual subscription" resource. + The response body shall be empty. + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + Subscriptions.Post.422: + description: > + 422 Unprocessable Content + + + Shall be returned upon the following error: The content type of the + message content is supported + + and the message content of a request contains syntactically correct data + but the data cannot be processed. + + The general cause for this error and its handling is specified in clause + 6.4 of ETSI + + GS NFV-SOL 013 [8], including rules for the presence of the response + body. + + Specifically in case of this resource, the response code 422 shall also + be returned if the VNFM has + + tested the Notification endpoint as described in clause 5.4.20.3.2 and + the test has failed. + + In this case, the "detail" attribute in the "ProblemDetails" structure + shall convey more + + information about the error. + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + Subscriptions.Get.200: + description: > + 200 OK + + + Shall be returned when the list of subscriptions has been queried + successfully. + + The response body shall contain in an array the representations of all + active subscriptions of + + the functional block that invokes the method, i.e. zero or more + representations of lifecycle change + + notification subscriptions as defined in clause 5.5.2.16. + + If the "filter" URI parameter was supplied in the request, the data in + the response body shall have been + + transformed according to the rules specified in clause 5.2.2 of ETSI GS + NFV-SOL 013. + + If the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 + of ETSI GS NFV-SOL 013 + + for this resource, inclusion of the Link HTTP header in this response + shall follow the provisions + + in clause 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: > + This type represents a subscription related to notifications + about VNF lifecycle changes. + type: object + required: + - id + - callbackUri + - verbosity + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: "This type represents a subscription filter related to notifications about VNF lifecycle changes.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of \n the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdId + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId + values listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, + from one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tVnfLcmOperationOccurrenceNotification -\tVnfIdentifierCreationNotification -\tVnfIdentifierDeletionNotification See note.\n" + type: array + items: + type: string + enum: + - VnfLcmOperationOccurrenceNotification + - VnfIdentifierCreationNotification + - VnfIdentifierDeletionNotification + operationTypes: + description: > + Match particular VNF lifecycle operation types for the + notification of type + VnfLcmOperationOccurrenceNotification. May be present if + the "notificationTypes" attribute contains the value + "VnfLcmOperationOccurrenceNotification", and shall be + absent otherwise. + type: array + items: + description: > + The enumeration LcmOpType defines the permitted values + to represent VNF lifecycle operation types in VNF + lifecycle management operation occurrence resources + and VNF lifecycle management operation occurrence + notifications. + + Value | Description ------|------------ INSTANTIATE | + Represents the "Instantiate VNF" LCM operation. + SCALE | Represents the "Scale VNF" LCM operation. + SCALE_TO_LEVEL | Represents the "Scale VNF to Level" + LCM operation. CHANGE_FLAVOUR | Represents the "Change + VNF Flavour" LCM operation. TERMINATE | Represents the + "Terminate VNF" LCM operation. HEAL | Represents the + "Heal VNF" LCM operation. OPERATE | Represents the + "Operate VNF" LCM operation. CHANGE_EXT_CONN | + Represents the "Change external VNF connectivity" LCM + operation. MODIFY_INFO | Represents the "Modify VNF + Information" LCM operation. CREATE_SNAPSHOT | + Represents the "Create VNF Snapshot" LCM operation. + REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF + Snapshot" LCM operation. CHANGE_VNFPKG | Represents + the "Change current VNF package" LCM operation. + SELECT_DEPL_MODS | Represents the “Select VNF + deployable modules” LCM operation + type: string + enum: + - INSTANTIATE + - SCALE + - SCALE_TO_LEVEL + - CHANGE_FLAVOUR + - TERMINATE + - HEAL + - OPERATE + - CHANGE_EXT_CONN + - MODIFY_INFO + - CREATE_SNAPSHOT + - REVERT_TO_SNAPSHOT + - CHANGE_VNFPKG + - SELECT_DEPL_MODS + operationStates: + description: > + Match particular LCM operation state values as reported + in notifications of type + VnfLcmOperationOccurrenceNotification. May be present if + the "notificationTypes" attribute contains the value + "VnfLcmOperationOccurrenceNotification", and shall be + absent otherwise. + type: array + items: + description: > + STARTING: The LCM operation is starting. PROCESSING: + The LCM operation is currently in execution. + COMPLETED: The LCM operation has been completed + successfully. FAILED_TEMP: The LCM operation has + failed and execution has stopped, but the execution of + the operation is not considered to be closed. FAILED: + The LCM operation has failed and it cannot be retried + or rolled back, as it is determined that such action + won't succeed. ROLLING_BACK: The LCM operation is + currently being rolled back. ROLLED_BACK: The LCM + operation has been successfully rolled back, i.e. The + state of the VNF prior to the original operation + invocation has been restored as closely as possible. + type: string + enum: + - STARTING + - PROCESSING + - COMPLETED + - FAILED_TEMP + - FAILED + - ROLLING_BACK + - ROLLED_BACK + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + verbosity: + description: > + The enumeration LcmOpOccNotificationVerbosityType provides + values to control the verbosity of LCM operation occurrence + notifications. * FULL: This signals a full notification + which contains all change details. * SHORT: This signals a + short notification which omits large-volume change details + to reduce the size of data to + be sent via the notification mechanism. + type: string + enum: + - FULL + - SHORT + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualSubscription.Get.200: + description: > + 200 OK + + + Shall be returned when information about an individual subscription has + been read successfully. + + The response body shall contain a representation of the "Individual + subscription" resource. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + This type represents a subscription related to notifications about + VNF lifecycle changes. + type: object + required: + - id + - callbackUri + - verbosity + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: "This type represents a subscription filter related to notifications about VNF lifecycle changes.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of \n the notification types to facilitate automated code generation systems.\n" + type: object + properties: + vnfInstanceSubscriptionFilter: + description: "This type represents subscription filter criteria to match VNF instances. * NOTE 1:\tThe attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances\n that are based on certain VNFDs in a filter. They should not be used both in the same filter instance,\n but one alternative should be chosen.\n NOTE 2:\tThe attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF\n instances in a filter. They should not be used both in the same filter instance, but one alternative\n should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfdId + - required: + - vnfProductsFromProviders + - oneOf: + - required: + - vnfInstanceIds + - required: + - vnfInstanceNames + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId values + listed in this attribute. See note 1. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. See note 1. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, from + one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. See note 2. + type: array + items: + type: string + notificationTypes: + description: "Match particular notification types. \nPermitted values: -\tVnfLcmOperationOccurrenceNotification -\tVnfIdentifierCreationNotification -\tVnfIdentifierDeletionNotification See note.\n" + type: array + items: + type: string + enum: + - VnfLcmOperationOccurrenceNotification + - VnfIdentifierCreationNotification + - VnfIdentifierDeletionNotification + operationTypes: + description: > + Match particular VNF lifecycle operation types for the + notification of type + VnfLcmOperationOccurrenceNotification. May be present if + the "notificationTypes" attribute contains the value + "VnfLcmOperationOccurrenceNotification", and shall be + absent otherwise. + type: array + items: + description: > + The enumeration LcmOpType defines the permitted values + to represent VNF lifecycle operation types in VNF + lifecycle management operation occurrence resources and + VNF lifecycle management operation occurrence + notifications. + + Value | Description ------|------------ INSTANTIATE | + Represents the "Instantiate VNF" LCM operation. SCALE + | Represents the "Scale VNF" LCM operation. + SCALE_TO_LEVEL | Represents the "Scale VNF to Level" LCM + operation. CHANGE_FLAVOUR | Represents the "Change VNF + Flavour" LCM operation. TERMINATE | Represents the + "Terminate VNF" LCM operation. HEAL | Represents the + "Heal VNF" LCM operation. OPERATE | Represents the + "Operate VNF" LCM operation. CHANGE_EXT_CONN | + Represents the "Change external VNF connectivity" LCM + operation. MODIFY_INFO | Represents the "Modify VNF + Information" LCM operation. CREATE_SNAPSHOT | Represents + the "Create VNF Snapshot" LCM operation. + REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF + Snapshot" LCM operation. CHANGE_VNFPKG | Represents the + "Change current VNF package" LCM operation. + SELECT_DEPL_MODS | Represents the “Select VNF deployable + modules” LCM operation + type: string + enum: + - INSTANTIATE + - SCALE + - SCALE_TO_LEVEL + - CHANGE_FLAVOUR + - TERMINATE + - HEAL + - OPERATE + - CHANGE_EXT_CONN + - MODIFY_INFO + - CREATE_SNAPSHOT + - REVERT_TO_SNAPSHOT + - CHANGE_VNFPKG + - SELECT_DEPL_MODS + operationStates: + description: > + Match particular LCM operation state values as reported in + notifications of type + VnfLcmOperationOccurrenceNotification. May be present if + the "notificationTypes" attribute contains the value + "VnfLcmOperationOccurrenceNotification", and shall be + absent otherwise. + type: array + items: + description: > + STARTING: The LCM operation is starting. PROCESSING: The + LCM operation is currently in execution. COMPLETED: The + LCM operation has been completed successfully. + FAILED_TEMP: The LCM operation has failed and execution + has stopped, but the execution of the operation is not + considered to be closed. FAILED: The LCM operation has + failed and it cannot be retried or rolled back, as it is + determined that such action won't succeed. ROLLING_BACK: + The LCM operation is currently being rolled back. + ROLLED_BACK: The LCM operation has been successfully + rolled back, i.e. The state of the VNF prior to the + original operation invocation has been restored as + closely as possible. + type: string + enum: + - STARTING + - PROCESSING + - COMPLETED + - FAILED_TEMP + - FAILED + - ROLLING_BACK + - ROLLED_BACK + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + verbosity: + description: > + The enumeration LcmOpOccNotificationVerbosityType provides + values to control the verbosity of LCM operation occurrence + notifications. * FULL: This signals a full notification which + contains all change details. * SHORT: This signals a short + notification which omits large-volume change details to reduce + the size of data to + be sent via the notification mechanism. + type: string + enum: + - FULL + - SHORT + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualSubscription.Delete.204: + description: > + 204 NO CONTENT + + + Shall be returned when the "Individual subscription" resource has been + deleted successfully. + + The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + CreateVnfSnapshotTask.Post.202: + description: > + 202 ACCEPTED + + + Shall be returned when the request was accepted for processing, but the + processing + + has not been completed. + + The response body shall be empty. + + The HTTP response shall include a "Location" HTTP header that contains + the URI of + + the newly-created "VNF LCM operation occurrence" resource corresponding + to the operation. + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + CreateVnfSnapshotTask.Post.404: + description: > + 404 NOT FOUND + + + SShall be returned upon the following error: The API producer did not + find a current representation for + + the target resource or is not willing to disclose that one exists. + + The general cause for this error and its handling is specified in clause + 6.4 of ETSI + + GS NFV-SOL 013 [8], including rules for the presence of the response + body. + + Specifically in case of this task resource, the response code 404 shall + also be returned if the task + + is not supported for the VNF instance represented by the parent + resource, which means that the task + + resource consequently does not exist. + + In this case, the response body shall be present, and shall contain a + ProblemDetails structure, in + + which the "detail" attribute shall convey more information about the + error + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + CreateVnfSnapshotTask.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that the VNF + instance resource is in NOT_INSTANTIATED state, + or that another lifecycle management operation is + ongoing. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + CreateVnfSnapshotTask.Post.422: + description: | + 422 Unprocessable Content + + Shall be returned upon the following error: The + content type of the message content is supported and + the message content of a request contains syntactically + correct data but the data cannot be processed. + The general cause for this error and its handling is + specified in clause 6.4 of ETSI + GS NFV-SOL 013 [8], including rules for the + presence of the response body. + Specifically in case of this resource, the response + code 422 shall also be returned if the provided + identifier of the target "Individual VNF snapshot" + resource for the VNF snapshot is invalid. + In this case, the "detail" attribute in the + "ProblemDetails" structure shall convey more + information about the error + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + RevertToVnfSnapshotTask.Post.202: + description: > + 202 ACCEPTED + + + Shall be returned when the request was accepted for processing, but the + processing has + + not been completed. + + The response body shall be empty. + + The HTTP response shall include a "Location" HTTP header that contains + the URI of + + the newly-created "VNF LCM operation occurrence" resource corresponding + to the operation. + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + RevertToVnfSnapshotTask.Post.404: + description: | + 404 NOT FOUND + + Shall be returned upon the following error: The API + producer did not find a current representation for the + target resource or is not willing to disclose that one + exists. + The general cause for this error and its handling is + specified in clause 6.4 of ETSI + GS NFV-SOL 013 [8], including rules for the + presence of the response body. + Specifically in case of this task resource, the + response code 404 shall also be returned if the task + is not supported for the VNF instance represented + by the parent resource, which means that the task + resource consequently does not exist. + In this case, the response body shall be present, + and shall contain a ProblemDetails structure, in + which the "detail" attribute shall convey more + information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + RevertToVnfSnapshotTask.Post.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that the VNF + instance resource is in NOT_INSTANTIATED state, + or that another lifecycle management operation is + ongoing. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + VnfSnapshots.Post.201: + description: > + 201 CREATED + + + Shall be returned when an "Individual VNF snapshot" resource has been + created + + successfully. + + The response body shall contain a representation of the new "Individual + VNF snapshot" + + resource, as defined in clause 5.5.2.22. + + The HTTP response shall include a "Location" HTTP header that contains + the resource URI + + of the "Individual VNF snapshot" resource. + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: | + This type represents an "Individual VNF snapshot" resource. + type: object + required: + - id + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfSnapshotPkgId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfSnapshot: + description: | + This type represents a VNF snapshot. + type: object + required: + - id + - vnfInstanceId + - triggeredAt + - vnfdId + - vnfInfo + - vnfcSnapshots + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + creationStartedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + creationFinishedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfInstance: + description: "This type represents a VNF instance.\nNOTE:\tClause B.3.2 provides examples illustrating the relationship among the different run-time \n information elements (CP, VL and link ports) used to represent the connectivity of a VNF.\n\nNOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist between \n the previous and the newly referred VNF package, i.e. when the new VNFD is changed with \n respect to the previous VNFD in other aspects than merely referencing to other VNF software \n images. In order to avoid misalignment of the VnfInstance with the current VNF's on-boarded \n VNF Package, the values of attributes in the VnfInstance that have corresponding attributes \n in the VNFD shall be kept in sync with the values in the VNFD.\nNOTE 2:\tETSI GS NFV-SOL 001 [14] specifies the structure and format of the VNFD based on TOSCA specifications. NOTE 3:\tVNF configurable properties are sometimes also referred to as configuration parameters applicable \n to a VNF. Some of these are set prior to instantiation and cannot be modified if the VNF is instantiated, \n some are set prior to instantiation (are part of initial configuration) and can be modified later, \n and others can be set only after instantiation. The applicability of certain configuration may \n depend on the VNF and the required operation of the VNF at a certain point in time.\nNOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes \n of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared in the VNFD with a defined \n initial value. The defined initial values can be declared in the VNFD, and/or, in case of \"metadata\", \n obtained from the \"CreateVnfRequest\" structure. Child attributes of \"vnfConfigurableProperties\", \n \"metadata\" and \"extensions\" that have no defined initial value shall not be created, in order to be \n consistent with the semantics of the JSON Merge Patch method (see IETF RFC 7396) that interprets null \n values as deletion request.\nNOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a \n multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same \n VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed \n multi-site VL instance (refer to clause 5.5.3.3).\nNOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity, they shall \n not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\nNOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing \n the trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\nNOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the \n VNF LCM operation explicitly indicates the scale level for the aspect.\nNOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n" + type: object + required: + - id + - vnfdId + - vnfProvider + - vnfProductName + - vnfSoftwareVersion + - vnfdVersion + - instantiationState + - _links + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceName: + description: > + Name of the VNF instance. This attribute can be + modified with the PATCH method. + type: string + vnfInstanceDescription: + description: > + Human-readable description of the VNF instance. This + attribute can be modified with the PATCH method. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProvider: + description: > + Provider of the VNF and the VNFD. The value is copied + from the VNFD. + type: string + vnfProductName: + description: > + Name to identify the VNF Product. The value is copied + from the VNFD. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + vimConnectionInfo: + description: > + Information about VIM or CISM connections to be used + for managing the resources for the VNF instance. The + keys of the map, each of which identifies information + about a particular VIM connection, are managed by the + NFVO and referenced from other data structures via the + "vimConnectionId" attribute. This attribute shall only + be supported and present if - the resources of at + least of the VNFCs are managed by a VIM and + VNF-related resource management in direct mode is + applicable. - the resources of at least of the VNFCs + are managed by a CISM. This attribute can be modified + with the PATCH method. If VIM connection information + is provisioned to the VNFM by means outside the scope + of the present document, the information in the + "vimConnectionInfo" attribute provides necessary + information for binding the VnfInstance representing + the "Individual VNF instance" to the applicable VIM + connection information used to perform resource + management for the VNF instance. See also the + definition of the "VimConnectionInfo" in clause + 4.4.1.6. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being + globally unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute + determines the structure of the "interfaceInfo" + and "accessInfo" attributes, based on the type + of the VIM., CISM, CIR or MCIOP repository. The + set of permitted values is expected to change + over time as new types or versions of VIMs + become available. The ETSI NFV registry of + VIM-related information provides access to + information about VimConnectionInfo definitions + for various VIM, CISM, CIR or MCIOP repository + types. The structure of the registry is defined + in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + cirConnectionInfo: + description: > + Information about the CIR connection for managing OS + container images for the VNF instance. Shall be + present when all or part of the VNF is realized by a + set of OS containers and shall be absent otherwise. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being + globally unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute + determines the structure of the "interfaceInfo" + and "accessInfo" attributes, based on the type + of the VIM., CISM, CIR or MCIOP repository. The + set of permitted values is expected to change + over time as new types or versions of VIMs + become available. The ETSI NFV registry of + VIM-related information provides access to + information about VimConnectionInfo definitions + for various VIM, CISM, CIR or MCIOP repository + types. The structure of the registry is defined + in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + mciopRepositoryInfo: + description: > + Information about the MCIOP repository for the VNF + instance. Shall be present when all or part of the VNF + is realized by a set of OS containers and shall be + absent otherwise. See note 1. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being + globally unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute + determines the structure of the "interfaceInfo" + and "accessInfo" attributes, based on the type + of the VIM., CISM, CIR or MCIOP repository. The + set of permitted values is expected to change + over time as new types or versions of VIMs + become available. The ETSI NFV registry of + VIM-related information provides access to + information about VimConnectionInfo definitions + for various VIM, CISM, CIR or MCIOP repository + types. The structure of the registry is defined + in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + certificateInfo: + description: > + This type provides input information related to + certificate and certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + certificateConfigurationInfo: + description: > + This type provides input information related to + certificate management. + type: object + required: + - securityPolicy + properties: + certificateBaseProfile: + description: Information for certificate profile. + type: array + items: + description: > + NOTE: At least one overriding attributes + shall be present, otherwise shall be absent. + + This type provides input information to + override certificate base profile for + certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + issuer: + description: Issuer of certificates. See note. + type: string + issuerUniqueIdentifier: + description: > + An identifier with the intention of + being globally unique. + type: string + subject: + description: > + This type provides input information + related to the subject of the + certificate. + + NOTE: At least one overriding attributes + shall be present, otherwise shall be + absent. + type: object + properties: + commonName: + description: > + Information of the certification target + subject FQDN. Can be set empty when this + certificate is used for encrypted + communication using IP address. See + note. + type: string + organization: + description: >- + Information of the certification target + subject Organization. See note. + type: string + country: + description: >- + Information of the certification target + subject Country. See note. + type: string + state: + description: >- + Information of the certification target + subject State. See note. + type: string + locality: + description: >- + Information of the certification target + subject Locality. See note. + type: string + emailAddress: + description: >- + Information of the certification contact + email address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of + being globally unique. + type: string + basicConstraints: + description: >- + Basic constraints of certificates. See + note. + type: string + issuerAltName: + description: >- + Alternative name of issuer of + certificates in this NS. See note. + type: array + items: + type: string + subjectAltName: + description: > + Alternative name of subject of + certificates. Shall be present when this + certificate is used for encrypted + communication using IP address and + subjectAltName attribute of + CertificateBaseProfile in + CertificateDesc of VNFD is empty (see + ETSI GS NFV-IFA 011 [14], clause + 7.1.19.4). See note. + type: array + items: + type: string + nameConstraints: + description: >- + Name constraints of certificates. See + note. + type: array + items: + type: string + securityPolicy: + description: >- + Information for security policy to be + satisfied for certificate. + type: array + items: + description: > + This type provides input information related + to security policy for certificate + management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + maxValidityPeriod: + description: >- + Allowed max validity period for + certificates. + type: number + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: number + delegationSupportedCertificateManagements: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + cmfInfo: + description: > + This type provides input information related + to CMF for certificate management. + type: object + required: + - id + - endPoint + - supportedProtocol + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + endPoint: + description: End point of CMF instance. + type: object + properties: + 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 + link: + description: > + This type represents a link to a + resource using an absolute URI. + type: object + required: + - href + properties: + href: + description: > + String formatted according to IETF RFC + 3986. + type: string + supportedProtocol: + description: Supported protocols by CMF instance. + type: array + items: + description: Supported protocol by CMF instance. + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + certificateChain: + description: Certificate chain that this CMF provides. + type: array + items: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + certificateContents: + description: > + Information for contents of issued certificates. + The information contained in this attribute may be + updated over time during the VNF LCM, e.g., + certificate(s) renewal. + type: array + items: + description: > + This type provides input information related to + certificate content. + + NOTE: The CertificateDesc data type is defined + in clause 7.1.19.2 of ETSI GS NFV IFA 011 [10]. + type: object + required: + - id + - certificateDescId + - certificateType + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + certificateDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + certificateType: + description: Type of this certificate. + type: string + enum: + - VNFCI_CERT + - VNFOAM_CERT + supportedCertificateManagements: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + version: + description: | + A version. + type: string + serialNumber: + description: Serial number of this certificate. + type: integer + signatureAlgorithm: + description: Algorithm of this certificate's signature. + type: string + issuer: + description: Issuer of this certificate. + type: string + notBefore: + description: > + Date-time stamp. Representation: String + formatted according to IETF RFC 3339. + type: string + format: date-time + notAfter: + description: > + Date-time stamp. Representation: String + formatted according to IETF RFC 3339. + type: string + format: date-time + subject: + description: Subject of this certificate. + type: string + publicKeyAlgorithm: + description: Algorithm of this certificate's public key. + type: string + publicKey: + description: Public key of this certificate. + type: string + certificateExtensions: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + instantiationState: + description: > + The instantiation state of the VNF. Permitted values: + - NOT_INSTANTIATED: The VNF instance is terminated or + not instantiated. - INSTANTIATED: The VNF instance is + instantiated. + type: string + enum: + - NOT_INSTANTIATED + - INSTANTIATED + instantiatedVnfInfo: + description: > + Information specific to an instantiated VNF instance. + This attribute shall be present if the + instantiateState attribute value is INSTANTIATED. + type: object + required: + - flavourId + - vnfState + properties: + flavourId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfState: + description: > + STARTED: The VNF instance is up and running. + STOPPED: The VNF instance has been shut down. + type: string + enum: + - STARTED + - STOPPED + vnfPowerState: + description: > + This type represents information about the power + state of a VNF instance. + type: object + required: + - powerProfileId + - name + properties: + powerProfileId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + name: + description: > + Name of the power profile as provided in the + VNFD. + type: string + powerConsumptionInfo: + description: > + This type represents information about + estimated power consumption of the resources + associated with the power profile, as provided + in the VNFD. + type: object + required: + - minPowerConsumption + - maxPowerConsumption + - averagePowerConsumption + properties: + minPowerConsumption: + description: > + Minimum power consumption of this power + profile. Unit is KW/h. + type: integer + maxPowerConsumption: + description: > + Maximum power consumption of this power + profile. Unit is KW/h. + type: integer + averagePowerConsumption: + description: > + Average power consumption of this power + profile. Unit is KW/h. + type: integer + scaleStatus: + description: > + Scale status of the VNF, one entry per aspect. + Represents for every scaling aspect how "big" the + VNF has been scaled w.r.t. that aspect. + + This attribute shall be present if the VNF + supports scaling. See clause B.2 for an + explanation of VNF scaling. + + For an aspect that has not been deployed because + the related deployableModule has not been + selected, it indicates the scale level that has + been requested in the instantiation or in a + scaling operation, or, if none has been requested + in any of them, the scale level applicable to the + aspect based on the default instantiation level. + See note 8. + type: array + items: + description: > + This type represents the scale level of a VNF + instance related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being + globally unique. + type: string + maxScaleLevels: + description: > + Maximum allowed scale levels of the VNF, one entry + per aspect. This attribute shall be present if the + VNF supports scaling. + type: array + items: + description: > + This type represents the scale level of a VNF + instance related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being + globally unique. + type: string + selectedDeployableModule: + description: > + References a currently selected deployable module, + as defined in the VNFD, that has already + completed the instantiation of its VNFCs. + type: array + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + resourceCapacityDefinition: + description: > + Shows current values of VDU attributes related to + resource capacity, if different to the default + values from the VNFD, as indicated in the (one or + more) request(s) of all completed VNF LCM + operation(s) that contain this attribute. If an + attribute value has been modified multiple times, + only the last value is shown. The values indicated + in this attribute are applicable to all VNFC + instances based on the VDU to which the + resourceCapacityDefinition is related. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes. + + * NOTE: Resource definitions not related to a + VDU are not considered in this version of the + present document. + type: object + required: + - type + properties: + tag: + description: > + Tag assigned by the issuer of a VNF LCM + operation request that contains this data + type with values to be applied to a VDU. It + is used for tracking purposes. + + The tag is preserved in the run time record + as long as at least one value of the + capacity related attributes associated with + that tag is still valid, i.e., it has not + been modified by a later VNF LCM operation + request. + + At most one tag can be included when the + data type is used in a VNF LCM operation + request. + + When the data type is used in the + VnfInstance data type it may contain + multiple tags, namely those provided in VNF + LCM requests, if at least one of the values + provided in that request associated to that + tag is still applicable in the VNFCs created + from this VDU, i.e., it has not been + modified by a later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: | + Type of the resource definition referenced. + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + osContainerDescData: + description: > + Indicates values for resource capacity + related attributes in an OsContainerDesc. + It shall be present when the attribute + 'type' indicates OSCONTAINER and absent + otherwise. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes of an + OsContainer resource. + + * NOTE: At least one of the attributes + shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for + the container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for + the container expressed in the same + units as specified in the + requested_memory_resources_valid_values + property in VNFD (clause 6.8.12 in ETSI + GS NFV-SOL 001 [14]) for this container + descriptor. See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources + of the type indicated in the key. The + key is a string that identifies an + extended resource indicated in the + extended_resource_requests property in + the VNFD (clause 6.8.12 in ETSI GS + NFV-SOL 001 [14]) for this container + descriptor. The value is an integer that + indicates the required amount for a + particular extended resource. See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container + can maximally use in milli-CPU. See + note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required + for all the hugepages of the size + indicated in the key. The key is a + string and corresponds to one of the + values of the hugepage sizes indicated + in the huge_pages_resources property in + the VNFD (clause 6.8.12 in ETSI GS + NFV-SOL 001 [14]) for this container + descriptor. The value is a number that + indicates the required total size + expressed in the same units as in the + huge_pages_resource property in the VNFD + (clause 6.8.12 in ETSI GS NFV-SOL 001 + [14]) that indicates the valid values + for required total size for the + particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power + state configuration data for the virtual + compute or OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU + cores are requested to be allocated to + logical CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states + of virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on + core utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for + capacity related VDU attributes of the + virtual compute resource of a VM. + + * NOTE: At least one of the attributes shall + be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required + for all the hugepages of the size + indicated in the key. The key is a + string and corresponds to one of the + values of the hugepage sizes indicated + in the huge_pages_requirements property + in the VNFD (clause 6.2.7.2 in ETSI GS + NFV-SOL 001 [14]) for this virtual + compute descriptor. The value is a + numberthat indicates the required total + size expressed in the same units as in + the huge_pages_requirements property in + the VNFD (clause 6.2.7.2 in ETSI GS + NFV-SOL 001 [14]) that indicates the + valid vaues for required total size for + the particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power + state configuration data for the virtual + compute or OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU + cores are requested to be allocated to + logical CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states + of virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on + core utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size + related attribute in an VirtualStorageDesc. + It shall be present when the attribute + 'type' indicates STORAGE and absent + otherwise. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes of the + virtual storage resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + extCpInfo: + description: > + Information about the external CPs exposed by the + VNF instance. When trunking is enabled, the list + of entries includes both, external CPs + corresponding to parent ports of a trunk, and + external CPs associated to sub-ports of a + trunk.See note 7. + type: array + items: + description: "This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n" + type: object + required: + - id + - cpdId + - cpConfigId + - cpProtocolInfo + oneOf: + - required: + - associatedVnfcCpId + - required: + - associatedVipCpId + - required: + - associatedVnfVirtualLinkId + properties: + id: + 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 + cpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolInfo: + description: | + Network protocol information for this CP. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + extLinkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + associatedVnfcCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVipCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVirtualCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVnfVirtualLinkId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceInfo” + structure that provides the specification of + the interface to attach the connection point + to a secondary container cluster network. + See notes 3 and 4. + + It shall be present if the external CP is + associated to a VNFC realized by one or a + set of OS containers and is connected to a + secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this VNF CP + instance uses. Shall be present when using + in delegation-mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + cpSecurityGroupInfo: + description: > + This type provides the list of active + security group rules applied to an external + CP instance. The type identifies which + "SecurityGroupRule" specified in the VNFD + are activated and the values of its + attributes. + type: object + required: + - securityGroupRuleId + - etherType + - protocol + - portRangeMin + - portRangeMax + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + description: + description: > + Human readable description of the + security group rule. + type: string + etherType: + description: > + Indicates the protocol carried over the + Ethernet layer. Permitted values: IPV4, + IPV6. + type: string + enum: + - IPV4 + - IPV6 + protocol: + description: > + Indicates the protocol carried over the + IP layer. Permitted values: any protocol + defined in the IANA protocol registry + (refer to clause 9.10.1.2 ofd ETSI GS + NFV-SOL 001 for further information). + type: string + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. + type: integer + vipCpInfo: + description: > + VIP CPs that are part of the VNF instance. Shall + be present when that particular VIP CP of the VNFC + instance is associated to an external CP of the + VNF instance. May be present otherwise. + type: array + minItems: 1 + items: + description: "This type provides information related to virtual IP (VIP) CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n" + type: object + required: + - cpInstanceId + - cpdId + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There + shall be one cpProtocolInfo for layer 3. + There may be one cpProtocolInfo for layer 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + associatedVnfcCpIds: + description: > + Identifiers of the VnfcCps that share the + virtual IP address allocated to the VIP CP + instance. See note. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + virtualCpInfo: + description: > + Virtual CPs that are part of the VNF instance. + Shall be present when a particular Virtual CP is + associated to an external CP of the VNF instance. + May be present otherwise. + type: array + items: + description: > + This type provides information related to a + virtual CP instance of a VNF. + + NOTE 1: A consumer of the VNF LCM interface can + learn the actual VNFC instances implementing the + service + accessible via the virtual CP instance by querying the "vnfcResourceInfo" from the "InstantiatedVnfInfo" + and filtering by corresponding "vduIds" values. + NOTE 2: The information can be omitted because + it is already available as part of the external + CP information in the + VnfExtCpInfo structure. + type: object + required: + - cpInstanceId + - cpdId + - resourceHandle + - vduIds + properties: + cpInstanceId: + 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 + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There + shall be one cpProtocolInfo for each layer + protocol supported. This attribute may be + omitted if the virtual CP is exposed as an + external CP. See note 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vduIds: + description: > + Reference to the VDU(s) which implement the + service accessible via the virtual CP + instance. See note 1. + type: array + minItems: 1 + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + additionalServiceInfo: + description: > + Additional service identification + information of the virtual CP instance. + type: array + items: + description: > + This type provides additional service + information of the virtual CP instance + used to expose properties of the virtual + CP to NFV-MANO. + + NOTE: This attribute shall only be present + if additional information is needed to + identify the service + termination within the VNF, such as for example a URL path information in an HTTP request required + to allow a single virtual CP IP address to be used for several HTTP based services that use the + same port number. + type: object + required: + - portInfo + properties: + portInfo: + description: > + Service port numbers exposed by the + virtual CP instance. + minItems: 1 + type: array + items: + description: > + This type describes the service + identifying port properties exposed by + the virtual CP instance. + type: object + required: + - name + - port + - portConfigurable + properties: + name: + description: > + The name of the port exposed by the + virtual CP instance. + type: string + protocol: + description: > + The L4 protocol for this port exposed by + the virtual CP instance. + + Permitted values: - TCP - UDP - SCTP + type: string + enum: + - TCP + - UDP + - SCTP + port: + description: > + The L4 port number exposed by the + virtual CP instance. + type: integer + portConfigurable: + description: > + The Boolean is a data type having two + values (true and false). + type: boolean + serviceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + extVirtualLinkInfo: + description: > + Information about the external VLs the VNF + instance is connected to. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the current + CP configuration information for the + connection of external CPs to the external + virtual link. See note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be + configured on the CP instances created + from the respective CPD. + + The key of the map which identifies the + individual VnfExtCpConfig entries is of + type "IdentifierInVnf" and is managed by + the NFVO. + + The entries shall be applied by the VNFM + according to the rules of JSON Merge + Patch (see IETF RFC 7396). See notes 2, + 3, 4, 5, 6. In case of deleting an + external CP, the list of instances to be + deleted. + type: object + additionalProperties: + description: > + This type represents an externally + provided link port, or a network + attachment definition resource of + secondary container cluster network, or + network address information per instance + of an external connection point. In the + case of VM-based deployment of the VNFC + exposing the external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based + deployment of the VNFC exposing the + external CP, the VNFM shall use the + network attachment definition resource + of secondary container cluster network + when connecting the CP to the external + VL. + + * NOTE 1: The following conditions apply + to the attributes "linkPortId" and + "cpProtocolData" for an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply + to the attributes “netAttDefResourceId” + and “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is + only applicable for specific cases where + more than one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but + not both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of + being globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create + a dedicated link port for the external + CP. If set to True, the VNFM shall + create a link port. If set to False, the + VNFM shall not create a link port. This + attribute is only applicable for + external CP instances without a floating + IP address that expose a VIP CP instance + for which a dedicated IP address is + allocated. It shall be present in that + case and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceData” structure that + provides the specification of the + interface to attach the external CP to a + secondary container cluster network. It + is only applicable if the external CP is + connected or to be connected to a + secondary container cluster network. It + shall not be present if the external CP + is related to a virtual network not + categorized as secondary container + cluster network. See notes 2, 3 and 4. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects + the CP to a VL and the domain names for + the external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security + groups. The parameters identify which + "SecurityGroupRule" specified in the + VNFD is activated/deactivated and for an + activated security group rule the values + of attributes defined in the VNFD that + can be overriden such as "portRangeMin" + and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extNetAttDefResource: + description: > + Network attachment definition resources that + provide the specification of the interface + to attach connection points to this VL. + type: array + items: + description: > + This type contains information related to + a network attachment definition resource + that provides the specification of the + interface used to connect one or multiple + connection points to a secondary + container cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of + being globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated + to this network attachment definition + resource. Shall be present when the + network attachment definition resource + is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to + this network attachment definition + resource. May be present when the + network attachment definition resource + is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and + been associated to the CP. + type: array + items: + type: string + extManagedVirtualLinkInfo: + description: > + Information about the externally-managed internal + VLs of the VNF instance. See notes 5 and 6. + type: array + items: + description: > + This type provides information about an + externally-managed virtual link. Note: Both + "vnfLinkPort" and "vnfNetAttDefResource" + attributes can be present in an + "ExtManagedVirtualLinkInfo" to + indicate that a single internal virtual link is providing connectivity for both VM-based and container-based + VNFCs. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + vnfLinkPorts: + description: | + Link ports of this VL. See note. + type: array + items: + description: > + This type represents a link port of an + internal VL of a VNF. + + NOTE 1: Either cpInstanceId with + cpInstanceType set to "EXT_CP" or any + combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 + provides examples for configurations where + both vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is + scoped by the value of "vimConnectionId" + in the "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vnfNetAttDefResource: + description: > + Network attachment definition resources that + provide the specification of the interface + to attach connection points to this VL. See + note. + type: array + items: + description: > + This type contains information related to + a network attachment definition resource + that provides the specification of the + interface used to connect one or multiple + connection points to a secondary + container cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of + being globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated + to this network attachment definition + resource. Shall be present when the + network attachment definition resource + is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to + this network attachment definition + resource. May be present when the + network attachment definition resource + is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + extManagedMultisiteVirtualLinkId: + description: > + An identifier with the intention of being + globally unique. + type: string + routingResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + monitoringParameters: + description: | + Active monitoring parameters. + type: array + items: + description: > + This type represents a monitoring parameter that + is tracked by the VNFM, + type: object + required: + - id + - performanceMetric + properties: + id: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + name: + description: > + Human readable name of the monitoring + parameter, as defined in the VNFD. + type: string + performanceMetric: + description: > + Performance metric that is monitored. This + attribute shall contain the related + "Measurement Name" value as defined in + clause 7.2 of ETSI GS NFV-IFA 027. + type: string + localizationLanguage: + description: > + Information about localization language of the VNF + (includes e.g. strings in the VNFD). The + localization languages supported by a VNF can be + declared in the VNFD, and localization language + selection can take place at instantiation time. + The value shall comply with the format defined in + IETF RFC 5646. + type: string + vnfcResourceInfo: + description: > + Information about the virtualised compute and + storage resources used by the VNFCs of the VNF + instance. + type: array + items: + description: "This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure of\n information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n a) For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n b) For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\nNOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on \n TOSCA specifications.\nNOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an \n internal VL that exposes an external CP. A VNFC CP is \"exposed as\" an external \n CP if it is connected directly to an external VL.\nNOTE 3:\tThe information can be omitted because it is already available as part of the \n external CP information.\nNOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\"\n structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVnfc\" structure in the VNF LCM operation occurrence notifications\n or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\nNOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment\n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. \nNOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n" + type: object + required: + - id + - vduId + - computeResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being + globally unique. + type: string + storageResourceIds: + description: > + References to the VirtualStorage resources + or references to Storage MCIOs. The value + refers to a VirtualStorageResourceInfo item + in the VnfInstance. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfcCpInfo: + description: > + CPs of the VNFC instance. Shall be present + when that particular CP of the VNFC + instance is exposed as an external CP of + the VNF instance or is connected to an + external CP of the VNF instance. See note + 2. May be present otherwise. See note 7. + type: array + items: + type: object + required: + - id + - cpdId + properties: + id: + 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 + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpProtocolInfo: + description: > + Network protocol information for this + CP. May be omitted if the VNFC CP is + exposed as an external CP. See note 3. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + parentCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceInfo” structure that + provides the specification of the + interface to attach the connection point + to a secondary container cluster + network. See notes 5 and 6. It shall be + present if the internal CP is associated + to a VNFC realized by one or a set of OS + containers and is connected to a + secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + certificateContentId: + description: > + Identifier(s) of the + "CertificateContent" structure that + provides the information of the + certificate(s) that this VNFC CP + instance uses. Shall be present when + using in delegation-mode. Otherwise + shall not be present. This attribute + shall be supported when delegation mode + in certificate management is applicable + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this VNFC instance + uses. Shall be present when using in + delegation-mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfVirtualLinkResourceInfo: + description: > + Information about the virtualised network + resources used by the VLs of the VNF instance. See + note 6. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used + by an internal VL instance in a VNF instance. + + Note: If only the value or the presence of this + attribute is changed in the + "VnfVirtualLinkResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires including + a related "AffectedVirtualLink" structure in the VNF LCM operation occurrence notifications or the + "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being + globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfLinkPorts: + description: > + Links ports of this VL. Shall be present + when the linkPort is used for external + connectivity by the VNF (refer to + VnfLinkPortInfo). May be present otherwise. + type: array + items: + description: > + This type represents a link port of an + internal VL of a VNF. + + NOTE 1: Either cpInstanceId with + cpInstanceType set to "EXT_CP" or any + combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 + provides examples for configurations where + both vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is + scoped by the value of "vimConnectionId" + in the "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + virtualStorageResourceInfo: + description: > + Information on the virtualised storage resource(s) + used as storage for the VNF instance. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used + by a VNF instance. + + Note: If only the value or the presence of this + attribute is changed in the + "VirtualStorageResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires + including a related "AffectedVirtualStorage" structure in the VNF LCM operation occurrence + notifications or the "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - virtualStorageDescId + - storageResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being + globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + mcioInfo: + description: > + Information on the MCIO(s) representing VNFC + instance(s) realized by one or a set of OS + containers and created from the same VDU for the + VNF instance. + type: array + items: + description: > + This type provides information about an MCIO + representing the set of VNFC instances realized + by one or a set of OS containers which have + been created based on the same VDU. Within the + CISM, an MCIO controller monitors the actual + state of an MCIO representing the set of VNFC + instances realized by one or a set of OS + containers and compare it to the desired state + For an MCIO related to a VDU that has the + attribute isNumOfInstancesClusterBased set to + FALSE the desired state is specified in the + respective declarative descriptor. For an MCIO + related to a VDU that has the attribute + isNumOfInstancesClusterBased set to TRUE, the + desired state is determined by the number of + CIS-nodes in the cluster that fulfil the VDU + requirements.as specified in the respective + declarative descriptor. It triggers actions + toward the CIS to align the actual to the + desired state. Monitoring the actual state + includes monitoring the number of MCIO instances + available at any specific point in time. In + addition, an MCIO controller maintains + properties and runtime information on the MCIO + instances which have been created based on the + same VDU. The McioInfo data structure provides + the runtime information on the MCIOs obtained + from the MCIO controller. + + NOTE: There are different types of MCIOs. The + set of VNFC instances based on the same VDU is + represented + by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type + of MCIO, e.g. a POD. + + Runtime information of the set of OS containers + realizing an individual VNFC instance is not + part of the McioInfo data structure; such + runtime information is provided in the + ResourceHandle data structure referenced from + the VnfcResourceInfo. The McioInfo does not + provide runtime information of a constituent + VNFC instance created based on a specific VDU. + + NOTE 1: The type of MCIO as specified in the + declarative descriptor of the MCIO, and that can + be read from + the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the + “kind” property of the declarative descriptor. + NOTE 2: If the attribute additionalInfo is + present, it may contain runtime information on + the actual and + desired state of the MCIO(s). + NOTE 3: When the container infrastructure + service is a Kubernetes® instance, the mcioId is + the combined + values from the kind and name fields of the Kubernetes resource object, separated by a slash. + Example: "Deployment/abcd". + NOTE 4: When the container infrastructure + service is a Kubernetes® instance, the mcioName + is the name + field of the resource object. + type: object + required: + - mcioId + - mcioName + - mcioNamespace + - vduId + - cismId + - mcioType + - desiredInstances + - availableInstances + properties: + mcioId: + description: > + An identifier with the intention of being + globally unique. + type: string + mcioName: + description: > + Human readable name of this MCIO. See note + 4. + type: string + mcioNamespace: + description: | + Namespace of this MCIO. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cismId: + description: > + An identifier with the intention of being + globally unique. + type: string + mcioType: + description: > + The type of MCIO. Specific values, their + semantics and associated MCIO types are + defined in clause 5.5.4.9. Additional + values are also permitted. See note 1. + type: string + enum: + - Deployment + - Statefulset + - DaemonSet + desiredInstances: + description: | + Number of desired MCIO instances. + type: integer + availableInstances: + description: | + Number of available MCIO instances. + type: integer + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this MCIO instance + uses. Shall be present when using in + delegation mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfPaasServiceInfo: + description: > + Information on the PaaS Services assigned and used + by the VNF instance. + type: array + items: + description: > + This type provides input information about a + PaaS Service that is used by a VNF instance. The + PaasServiceInfo is comprised of various sets of + information. Some information comes from the + VNFD, other information comes from the PaaS + Service assets provided by the NFVO to the VNFM, + and other information is provided at runtime + information about the usage of the PaaS Service. + type: object + required: + - id + - paasServiceId + - paasServiceType + - paasServiceRequestId + - paasServiceHandle + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being + globally unique. + type: string + paasServiceType: + description: >- + The type of PaaS Service. The value of this + attribute is expected to be matched against + values of the registered PaaS Services in + the PSR. + type: string + paasServiceVersion: + description: | + A version. + type: string + paasServiceRequestId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + paasServiceHandle: + description: > + This type provides information enabling the + access and use of the PaaS Service by the + VNF instance. The type and format of the + handle depends on the form that the PaaS + Service is formed. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + indicators: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + instantiate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + terminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + heal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + operate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + createSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + revertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeCurrentVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperationLinks: + description: > + Links to the most recent LCM operation occurrences + related to this resource. See note 9. + type: object + properties: + recentVnfLcmOperation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmInstantiation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmTerminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmHeal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmModifyInfo: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmCreateSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmRevertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmSelectDplMods: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfcSnapshots: + description: > + Information about VNFC snapshots constituting this VNF + snapshot. + type: array + items: + description: "This type represents a VNFC snapshot.\nNOTE 1:\tThe identifier of the compute snapshot resource is assigned during creation of a VNFC snapshot \n being returned from the VIM as output data in the response message of the individual resource \n operations. This attribute shall only be present for a VNFC snapshot that has been newly created \n by the VNFM as a result of the \"Create VNF snapshot task\".\nNOTE 2:\tThe identifier of the storage snapshot resource is assigned during creation of a VNFC snapshot being \n returned from the VIM as output data in the response message of the individual resource operations. \n This attribute shall only be present for a VNFC snapshot with an associated storage resource and that \n has been newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n" + type: object + required: + - id + - vnfcInstanceId + - triggeredAt + - vnfcResourceId + properties: + id: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + vnfcInstanceId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + creationStartedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + creationFinishedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + vnfcResourceInfoId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + computeSnapshotResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + storageSnapshotResources: + description: > + Mapping of the storage resources associated to the + VNFC with the storage snapshot resources. + type: array + items: + type: object + required: + - storageResourceId + properties: + storageResourceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + storageSnapshotResource: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + userDefinedData: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + vnfStateSnapshotInfo: + description: > + This type represents information about VNF-specific state + snapshot data. + type: object + required: + - checksum + - isEncrypted + properties: + checksum: + description: | + Cheksum description + type: string + isEncrypted: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + userDefinedData: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfStateSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + takenFrom: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + VnfSnapshots.Get.200: + description: > + 200 OK + + + Shall be returned when information about zero or more VNF snapshots was + queried successfully. + + The response body shall contain in an array the representations of zero + or more + + "Individual VNF snapshot" resources, as defined in clause 5.5.2.22. + + If the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 + of ETSI GS NFV-SOL 013 + + for this resource, inclusion of the Link HTTP header in this response + shall follow the provisions + + in clause 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: | + This type represents an "Individual VNF snapshot" resource. + type: object + required: + - id + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfSnapshotPkgId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfSnapshot: + description: | + This type represents a VNF snapshot. + type: object + required: + - id + - vnfInstanceId + - triggeredAt + - vnfdId + - vnfInfo + - vnfcSnapshots + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceId: + description: > + An identifier with the intention of being globally + unique. + type: string + creationStartedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + creationFinishedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstance: + description: "This type represents a VNF instance.\nNOTE:\tClause B.3.2 provides examples illustrating the relationship among the different run-time \n information elements (CP, VL and link ports) used to represent the connectivity of a VNF.\n\nNOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist between \n the previous and the newly referred VNF package, i.e. when the new VNFD is changed with \n respect to the previous VNFD in other aspects than merely referencing to other VNF software \n images. In order to avoid misalignment of the VnfInstance with the current VNF's on-boarded \n VNF Package, the values of attributes in the VnfInstance that have corresponding attributes \n in the VNFD shall be kept in sync with the values in the VNFD.\nNOTE 2:\tETSI GS NFV-SOL 001 [14] specifies the structure and format of the VNFD based on TOSCA specifications. NOTE 3:\tVNF configurable properties are sometimes also referred to as configuration parameters applicable \n to a VNF. Some of these are set prior to instantiation and cannot be modified if the VNF is instantiated, \n some are set prior to instantiation (are part of initial configuration) and can be modified later, \n and others can be set only after instantiation. The applicability of certain configuration may \n depend on the VNF and the required operation of the VNF at a certain point in time.\nNOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes \n of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared in the VNFD with a defined \n initial value. The defined initial values can be declared in the VNFD, and/or, in case of \"metadata\", \n obtained from the \"CreateVnfRequest\" structure. Child attributes of \"vnfConfigurableProperties\", \n \"metadata\" and \"extensions\" that have no defined initial value shall not be created, in order to be \n consistent with the semantics of the JSON Merge Patch method (see IETF RFC 7396) that interprets null \n values as deletion request.\nNOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a \n multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same \n VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed \n multi-site VL instance (refer to clause 5.5.3.3).\nNOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity, they shall \n not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\nNOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing \n the trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\nNOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the \n VNF LCM operation explicitly indicates the scale level for the aspect.\nNOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n" + type: object + required: + - id + - vnfdId + - vnfProvider + - vnfProductName + - vnfSoftwareVersion + - vnfdVersion + - instantiationState + - _links + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceName: + description: > + Name of the VNF instance. This attribute can be + modified with the PATCH method. + type: string + vnfInstanceDescription: + description: > + Human-readable description of the VNF instance. This + attribute can be modified with the PATCH method. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProvider: + description: > + Provider of the VNF and the VNFD. The value is + copied from the VNFD. + type: string + vnfProductName: + description: > + Name to identify the VNF Product. The value is + copied from the VNFD. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + vimConnectionInfo: + description: > + Information about VIM or CISM connections to be used + for managing the resources for the VNF instance. The + keys of the map, each of which identifies + information about a particular VIM connection, are + managed by the NFVO and referenced from other data + structures via the "vimConnectionId" attribute. This + attribute shall only be supported and present if - + the resources of at least of the VNFCs are managed + by a VIM and VNF-related resource management in + direct mode is applicable. - the resources of at + least of the VNFCs are managed by a CISM. This + attribute can be modified with the PATCH method. If + VIM connection information is provisioned to the + VNFM by means outside the scope of the present + document, the information in the "vimConnectionInfo" + attribute provides necessary information for binding + the VnfInstance representing the "Individual VNF + instance" to the applicable VIM connection + information used to perform resource management for + the VNF instance. See also the definition of the + "VimConnectionInfo" in clause 4.4.1.6. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being + globally unique. + type: string + vimType: + description: > + Discriminator for the different types of the + VIM information. The value of this attribute + determines the structure of the + "interfaceInfo" and "accessInfo" attributes, + based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values + is expected to change over time as new types + or versions of VIMs become available. The ETSI + NFV registry of VIM-related information + provides access to information about + VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The + structure of the registry is defined in annex + C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + extra: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + cirConnectionInfo: + description: > + Information about the CIR connection for managing OS + container images for the VNF instance. Shall be + present when all or part of the VNF is realized by a + set of OS containers and shall be absent otherwise. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being + globally unique. + type: string + vimType: + description: > + Discriminator for the different types of the + VIM information. The value of this attribute + determines the structure of the + "interfaceInfo" and "accessInfo" attributes, + based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values + is expected to change over time as new types + or versions of VIMs become available. The ETSI + NFV registry of VIM-related information + provides access to information about + VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The + structure of the registry is defined in annex + C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + extra: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + mciopRepositoryInfo: + description: > + Information about the MCIOP repository for the VNF + instance. Shall be present when all or part of the + VNF is realized by a set of OS containers and shall + be absent otherwise. See note 1. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being + globally unique. + type: string + vimType: + description: > + Discriminator for the different types of the + VIM information. The value of this attribute + determines the structure of the + "interfaceInfo" and "accessInfo" attributes, + based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values + is expected to change over time as new types + or versions of VIMs become available. The ETSI + NFV registry of VIM-related information + provides access to information about + VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The + structure of the registry is defined in annex + C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + extra: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + certificateInfo: + description: > + This type provides input information related to + certificate and certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + certificateConfigurationInfo: + description: > + This type provides input information related to + certificate management. + type: object + required: + - securityPolicy + properties: + certificateBaseProfile: + description: Information for certificate profile. + type: array + items: + description: > + NOTE: At least one overriding attributes + shall be present, otherwise shall be + absent. + + This type provides input information to + override certificate base profile for + certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + issuer: + description: Issuer of certificates. See note. + type: string + issuerUniqueIdentifier: + description: > + An identifier with the intention of + being globally unique. + type: string + subject: + description: > + This type provides input information + related to the subject of the + certificate. + + NOTE: At least one overriding attributes + shall be present, otherwise shall be + absent. + type: object + properties: + commonName: + description: > + Information of the certification target + subject FQDN. Can be set empty when this + certificate is used for encrypted + communication using IP address. See + note. + type: string + organization: + description: >- + Information of the certification target + subject Organization. See note. + type: string + country: + description: >- + Information of the certification target + subject Country. See note. + type: string + state: + description: >- + Information of the certification target + subject State. See note. + type: string + locality: + description: >- + Information of the certification target + subject Locality. See note. + type: string + emailAddress: + description: >- + Information of the certification contact + email address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of + being globally unique. + type: string + basicConstraints: + description: >- + Basic constraints of certificates. See + note. + type: string + issuerAltName: + description: >- + Alternative name of issuer of + certificates in this NS. See note. + type: array + items: + type: string + subjectAltName: + description: > + Alternative name of subject of + certificates. Shall be present when this + certificate is used for encrypted + communication using IP address and + subjectAltName attribute of + CertificateBaseProfile in + CertificateDesc of VNFD is empty (see + ETSI GS NFV-IFA 011 [14], clause + 7.1.19.4). See note. + type: array + items: + type: string + nameConstraints: + description: >- + Name constraints of certificates. See + note. + type: array + items: + type: string + securityPolicy: + description: >- + Information for security policy to be + satisfied for certificate. + type: array + items: + description: > + This type provides input information + related to security policy for certificate + management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + maxValidityPeriod: + description: >- + Allowed max validity period for + certificates. + type: number + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: number + delegationSupportedCertificateManagements: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + cmfInfo: + description: > + This type provides input information related + to CMF for certificate management. + type: object + required: + - id + - endPoint + - supportedProtocol + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + endPoint: + description: End point of CMF instance. + type: object + properties: + 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 + link: + description: > + This type represents a link to a + resource using an absolute URI. + type: object + required: + - href + properties: + href: + description: > + String formatted according to IETF RFC + 3986. + type: string + supportedProtocol: + description: Supported protocols by CMF instance. + type: array + items: + description: Supported protocol by CMF instance. + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + certificateChain: + description: >- + Certificate chain that this CMF + provides. + type: array + items: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + certificateContents: + description: > + Information for contents of issued certificates. + The information contained in this attribute may + be updated over time during the VNF LCM, e.g., + certificate(s) renewal. + type: array + items: + description: > + This type provides input information related + to certificate content. + + NOTE: The CertificateDesc data type is defined + in clause 7.1.19.2 of ETSI GS NFV IFA 011 + [10]. + type: object + required: + - id + - certificateDescId + - certificateType + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + certificateDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + certificateType: + description: Type of this certificate. + type: string + enum: + - VNFCI_CERT + - VNFOAM_CERT + supportedCertificateManagements: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + version: + description: | + A version. + type: string + serialNumber: + description: Serial number of this certificate. + type: integer + signatureAlgorithm: + description: Algorithm of this certificate's signature. + type: string + issuer: + description: Issuer of this certificate. + type: string + notBefore: + description: > + Date-time stamp. Representation: String + formatted according to IETF RFC 3339. + type: string + format: date-time + notAfter: + description: > + Date-time stamp. Representation: String + formatted according to IETF RFC 3339. + type: string + format: date-time + subject: + description: Subject of this certificate. + type: string + publicKeyAlgorithm: + description: >- + Algorithm of this certificate's public + key. + type: string + publicKey: + description: Public key of this certificate. + type: string + certificateExtensions: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + instantiationState: + description: > + The instantiation state of the VNF. Permitted + values: - NOT_INSTANTIATED: The VNF instance is + terminated or not instantiated. - INSTANTIATED: The + VNF instance is instantiated. + type: string + enum: + - NOT_INSTANTIATED + - INSTANTIATED + instantiatedVnfInfo: + description: > + Information specific to an instantiated VNF + instance. This attribute shall be present if the + instantiateState attribute value is INSTANTIATED. + type: object + required: + - flavourId + - vnfState + properties: + flavourId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfState: + description: > + STARTED: The VNF instance is up and running. + STOPPED: The VNF instance has been shut down. + type: string + enum: + - STARTED + - STOPPED + vnfPowerState: + description: > + This type represents information about the power + state of a VNF instance. + type: object + required: + - powerProfileId + - name + properties: + powerProfileId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + name: + description: > + Name of the power profile as provided in the + VNFD. + type: string + powerConsumptionInfo: + description: > + This type represents information about + estimated power consumption of the resources + associated with the power profile, as + provided in the VNFD. + type: object + required: + - minPowerConsumption + - maxPowerConsumption + - averagePowerConsumption + properties: + minPowerConsumption: + description: > + Minimum power consumption of this power + profile. Unit is KW/h. + type: integer + maxPowerConsumption: + description: > + Maximum power consumption of this power + profile. Unit is KW/h. + type: integer + averagePowerConsumption: + description: > + Average power consumption of this power + profile. Unit is KW/h. + type: integer + scaleStatus: + description: > + Scale status of the VNF, one entry per aspect. + Represents for every scaling aspect how "big" + the VNF has been scaled w.r.t. that aspect. + + This attribute shall be present if the VNF + supports scaling. See clause B.2 for an + explanation of VNF scaling. + + For an aspect that has not been deployed because + the related deployableModule has not been + selected, it indicates the scale level that has + been requested in the instantiation or in a + scaling operation, or, if none has been + requested in any of them, the scale level + applicable to the aspect based on the default + instantiation level. See note 8. + type: array + items: + description: > + This type represents the scale level of a VNF + instance related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being + globally unique. + type: string + maxScaleLevels: + description: > + Maximum allowed scale levels of the VNF, one + entry per aspect. This attribute shall be + present if the VNF supports scaling. + type: array + items: + description: > + This type represents the scale level of a VNF + instance related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being + globally unique. + type: string + selectedDeployableModule: + description: > + References a currently selected deployable + module, as defined in the VNFD, that has + already completed the instantiation of its + VNFCs. + type: array + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + resourceCapacityDefinition: + description: > + Shows current values of VDU attributes related + to resource capacity, if different to the + default values from the VNFD, as indicated in + the (one or more) request(s) of all completed + VNF LCM operation(s) that contain this + attribute. If an attribute value has been + modified multiple times, only the last value is + shown. The values indicated in this attribute + are applicable to all VNFC instances based on + the VDU to which the resourceCapacityDefinition + is related. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes. + + * NOTE: Resource definitions not related to a + VDU are not considered in this version of the + present document. + type: object + required: + - type + properties: + tag: + description: > + Tag assigned by the issuer of a VNF LCM + operation request that contains this data + type with values to be applied to a VDU. + It is used for tracking purposes. + + The tag is preserved in the run time + record as long as at least one value of + the capacity related attributes + associated with that tag is still valid, + i.e., it has not been modified by a later + VNF LCM operation request. + + At most one tag can be included when the + data type is used in a VNF LCM operation + request. + + When the data type is used in the + VnfInstance data type it may contain + multiple tags, namely those provided in + VNF LCM requests, if at least one of the + values provided in that request associated + to that tag is still applicable in the + VNFCs created from this VDU, i.e., it has + not been modified by a later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: > + Type of the resource definition + referenced. + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + osContainerDescData: + description: > + Indicates values for resource capacity + related attributes in an OsContainerDesc. + It shall be present when the attribute + 'type' indicates OSCONTAINER and absent + otherwise. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes of an + OsContainer resource. + + * NOTE: At least one of the attributes + shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for + the container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for + the container expressed in the same + units as specified in the + requested_memory_resources_valid_values + property in VNFD (clause 6.8.12 in ETSI + GS NFV-SOL 001 [14]) for this container + descriptor. See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources + of the type indicated in the key. The + key is a string that identifies an + extended resource indicated in the + extended_resource_requests property in + the VNFD (clause 6.8.12 in ETSI GS + NFV-SOL 001 [14]) for this container + descriptor. The value is an integer that + indicates the required amount for a + particular extended resource. See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container + can maximally use in milli-CPU. See + note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required + for all the hugepages of the size + indicated in the key. The key is a + string and corresponds to one of the + values of the hugepage sizes indicated + in the huge_pages_resources property in + the VNFD (clause 6.8.12 in ETSI GS + NFV-SOL 001 [14]) for this container + descriptor. The value is a number that + indicates the required total size + expressed in the same units as in the + huge_pages_resource property in the VNFD + (clause 6.8.12 in ETSI GS NFV-SOL 001 + [14]) that indicates the valid values + for required total size for the + particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power + state configuration data for the virtual + compute or OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU + cores are requested to be allocated to + logical CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states + of virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on + core utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for + capacity related VDU attributes of the + virtual compute resource of a VM. + + * NOTE: At least one of the attributes + shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required + for all the hugepages of the size + indicated in the key. The key is a + string and corresponds to one of the + values of the hugepage sizes indicated + in the huge_pages_requirements property + in the VNFD (clause 6.2.7.2 in ETSI GS + NFV-SOL 001 [14]) for this virtual + compute descriptor. The value is a + numberthat indicates the required total + size expressed in the same units as in + the huge_pages_requirements property in + the VNFD (clause 6.2.7.2 in ETSI GS + NFV-SOL 001 [14]) that indicates the + valid vaues for required total size for + the particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power + state configuration data for the virtual + compute or OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU + cores are requested to be allocated to + logical CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states + of virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on + core utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size + related attribute in an + VirtualStorageDesc. It shall be present + when the attribute 'type' indicates + STORAGE and absent otherwise. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes of the + virtual storage resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + extCpInfo: + description: > + Information about the external CPs exposed by + the VNF instance. When trunking is enabled, the + list of entries includes both, external CPs + corresponding to parent ports of a trunk, and + external CPs associated to sub-ports of a + trunk.See note 7. + type: array + items: + description: "This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n" + type: object + required: + - id + - cpdId + - cpConfigId + - cpProtocolInfo + oneOf: + - required: + - associatedVnfcCpId + - required: + - associatedVipCpId + - required: + - associatedVnfVirtualLinkId + properties: + id: + 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 + cpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolInfo: + description: | + Network protocol information for this CP. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + extLinkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + associatedVnfcCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVipCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVirtualCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVnfVirtualLinkId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceInfo” + structure that provides the specification + of the interface to attach the connection + point to a secondary container cluster + network. See notes 3 and 4. + + It shall be present if the external CP is + associated to a VNFC realized by one or a + set of OS containers and is connected to a + secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this VNF CP + instance uses. Shall be present when using + in delegation-mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + cpSecurityGroupInfo: + description: > + This type provides the list of active + security group rules applied to an + external CP instance. The type identifies + which "SecurityGroupRule" specified in the + VNFD are activated and the values of its + attributes. + type: object + required: + - securityGroupRuleId + - etherType + - protocol + - portRangeMin + - portRangeMax + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + description: + description: > + Human readable description of the + security group rule. + type: string + etherType: + description: > + Indicates the protocol carried over the + Ethernet layer. Permitted values: IPV4, + IPV6. + type: string + enum: + - IPV4 + - IPV6 + protocol: + description: > + Indicates the protocol carried over the + IP layer. Permitted values: any protocol + defined in the IANA protocol registry + (refer to clause 9.10.1.2 ofd ETSI GS + NFV-SOL 001 for further information). + type: string + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. + type: integer + vipCpInfo: + description: > + VIP CPs that are part of the VNF instance. Shall + be present when that particular VIP CP of the + VNFC instance is associated to an external CP of + the VNF instance. May be present otherwise. + type: array + minItems: 1 + items: + description: "This type provides information related to virtual IP (VIP) CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n" + type: object + required: + - cpInstanceId + - cpdId + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There + shall be one cpProtocolInfo for layer 3. + There may be one cpProtocolInfo for layer + 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + associatedVnfcCpIds: + description: > + Identifiers of the VnfcCps that share the + virtual IP address allocated to the VIP CP + instance. See note. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + virtualCpInfo: + description: > + Virtual CPs that are part of the VNF instance. + Shall be present when a particular Virtual CP is + associated to an external CP of the VNF + instance. May be present otherwise. + type: array + items: + description: > + This type provides information related to a + virtual CP instance of a VNF. + + NOTE 1: A consumer of the VNF LCM interface + can learn the actual VNFC instances + implementing the service + accessible via the virtual CP instance by querying the "vnfcResourceInfo" from the "InstantiatedVnfInfo" + and filtering by corresponding "vduIds" values. + NOTE 2: The information can be omitted because + it is already available as part of the + external CP information in the + VnfExtCpInfo structure. + type: object + required: + - cpInstanceId + - cpdId + - resourceHandle + - vduIds + properties: + cpInstanceId: + 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 + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId shall + be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There + shall be one cpProtocolInfo for each layer + protocol supported. This attribute may be + omitted if the virtual CP is exposed as an + external CP. See note 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vduIds: + description: > + Reference to the VDU(s) which implement + the service accessible via the virtual CP + instance. See note 1. + type: array + minItems: 1 + items: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + additionalServiceInfo: + description: > + Additional service identification + information of the virtual CP instance. + type: array + items: + description: > + This type provides additional service + information of the virtual CP instance + used to expose properties of the + virtual CP to NFV-MANO. + + NOTE: This attribute shall only be + present if additional information is + needed to identify the service + termination within the VNF, such as for example a URL path information in an HTTP request required + to allow a single virtual CP IP address to be used for several HTTP based services that use the + same port number. + type: object + required: + - portInfo + properties: + portInfo: + description: > + Service port numbers exposed by the + virtual CP instance. + minItems: 1 + type: array + items: + description: > + This type describes the service + identifying port properties exposed by + the virtual CP instance. + type: object + required: + - name + - port + - portConfigurable + properties: + name: + description: > + The name of the port exposed by the + virtual CP instance. + type: string + protocol: + description: > + The L4 protocol for this port exposed by + the virtual CP instance. + + Permitted values: - TCP - UDP - SCTP + type: string + enum: + - TCP + - UDP + - SCTP + port: + description: > + The L4 port number exposed by the + virtual CP instance. + type: integer + portConfigurable: + description: > + The Boolean is a data type having two + values (true and false). + type: boolean + serviceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + extVirtualLinkInfo: + description: > + Information about the external VLs the VNF + instance is connected to. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId shall + be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the + current CP configuration information for + the connection of external CPs to the + external virtual link. See note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be + configured on the CP instances created + from the respective CPD. + + The key of the map which identifies the + individual VnfExtCpConfig entries is of + type "IdentifierInVnf" and is managed by + the NFVO. + + The entries shall be applied by the VNFM + according to the rules of JSON Merge + Patch (see IETF RFC 7396). See notes 2, + 3, 4, 5, 6. In case of deleting an + external CP, the list of instances to be + deleted. + type: object + additionalProperties: + description: > + This type represents an externally + provided link port, or a network + attachment definition resource of + secondary container cluster network, or + network address information per instance + of an external connection point. In the + case of VM-based deployment of the VNFC + exposing the external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based + deployment of the VNFC exposing the + external CP, the VNFM shall use the + network attachment definition resource + of secondary container cluster network + when connecting the CP to the external + VL. + + * NOTE 1: The following conditions apply + to the attributes "linkPortId" and + "cpProtocolData" for an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply + to the attributes “netAttDefResourceId” + and “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is + only applicable for specific cases where + more than one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but + not both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of + being globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create + a dedicated link port for the external + CP. If set to True, the VNFM shall + create a link port. If set to False, the + VNFM shall not create a link port. This + attribute is only applicable for + external CP instances without a floating + IP address that expose a VIP CP instance + for which a dedicated IP address is + allocated. It shall be present in that + case and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceData” structure that + provides the specification of the + interface to attach the external CP to a + secondary container cluster network. It + is only applicable if the external CP is + connected or to be connected to a + secondary container cluster network. It + shall not be present if the external CP + is related to a virtual network not + categorized as secondary container + cluster network. See notes 2, 3 and 4. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects + the CP to a VL and the domain names for + the external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security + groups. The parameters identify which + "SecurityGroupRule" specified in the + VNFD is activated/deactivated and for an + activated security group rule the values + of attributes defined in the VNFD that + can be overriden such as "portRangeMin" + and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extNetAttDefResource: + description: > + Network attachment definition resources + that provide the specification of the + interface to attach connection points to + this VL. + type: array + items: + description: > + This type contains information related + to a network attachment definition + resource that provides the + specification of the interface used to + connect one or multiple connection + points to a secondary container cluster + network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of + being globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated + to this network attachment definition + resource. Shall be present when the + network attachment definition resource + is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to + this network attachment definition + resource. May be present when the + network attachment definition resource + is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + extManagedVirtualLinkInfo: + description: > + Information about the externally-managed + internal VLs of the VNF instance. See notes 5 + and 6. + type: array + items: + description: > + This type provides information about an + externally-managed virtual link. Note: Both + "vnfLinkPort" and "vnfNetAttDefResource" + attributes can be present in an + "ExtManagedVirtualLinkInfo" to + indicate that a single internal virtual link is providing connectivity for both VM-based and container-based + VNFCs. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId shall + be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + vnfLinkPorts: + description: | + Link ports of this VL. See note. + type: array + items: + description: > + This type represents a link port of an + internal VL of a VNF. + + NOTE 1: Either cpInstanceId with + cpInstanceType set to "EXT_CP" or any + combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 + provides examples for configurations + where both vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" + is scoped by the value of + "vimConnectionId" in the + "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vnfNetAttDefResource: + description: > + Network attachment definition resources + that provide the specification of the + interface to attach connection points to + this VL. See note. + type: array + items: + description: > + This type contains information related + to a network attachment definition + resource that provides the + specification of the interface used to + connect one or multiple connection + points to a secondary container cluster + network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of + being globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated + to this network attachment definition + resource. Shall be present when the + network attachment definition resource + is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to + this network attachment definition + resource. May be present when the + network attachment definition resource + is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + extManagedMultisiteVirtualLinkId: + description: > + An identifier with the intention of being + globally unique. + type: string + routingResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId shall + be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + monitoringParameters: + description: | + Active monitoring parameters. + type: array + items: + description: > + This type represents a monitoring parameter + that is tracked by the VNFM, + type: object + required: + - id + - performanceMetric + properties: + id: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + name: + description: > + Human readable name of the monitoring + parameter, as defined in the VNFD. + type: string + performanceMetric: + description: > + Performance metric that is monitored. This + attribute shall contain the related + "Measurement Name" value as defined in + clause 7.2 of ETSI GS NFV-IFA 027. + type: string + localizationLanguage: + description: > + Information about localization language of the + VNF (includes e.g. strings in the VNFD). The + localization languages supported by a VNF can be + declared in the VNFD, and localization language + selection can take place at instantiation time. + The value shall comply with the format defined + in IETF RFC 5646. + type: string + vnfcResourceInfo: + description: > + Information about the virtualised compute and + storage resources used by the VNFCs of the VNF + instance. + type: array + items: + description: "This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure of\n information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n a) For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n b) For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\nNOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on \n TOSCA specifications.\nNOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an \n internal VL that exposes an external CP. A VNFC CP is \"exposed as\" an external \n CP if it is connected directly to an external VL.\nNOTE 3:\tThe information can be omitted because it is already available as part of the \n external CP information.\nNOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\"\n structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVnfc\" structure in the VNF LCM operation occurrence notifications\n or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\nNOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment\n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. \nNOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n" + type: object + required: + - id + - vduId + - computeResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId shall + be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being + globally unique. + type: string + storageResourceIds: + description: > + References to the VirtualStorage resources + or references to Storage MCIOs. The value + refers to a VirtualStorageResourceInfo + item in the VnfInstance. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfcCpInfo: + description: > + CPs of the VNFC instance. Shall be present + when that particular CP of the VNFC + instance is exposed as an external CP of + the VNF instance or is connected to an + external CP of the VNF instance. See note + 2. May be present otherwise. See note 7. + type: array + items: + type: object + required: + - id + - cpdId + properties: + id: + 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 + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpProtocolInfo: + description: > + Network protocol information for this + CP. May be omitted if the VNFC CP is + exposed as an external CP. See note 3. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + parentCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceInfo” structure that + provides the specification of the + interface to attach the connection point + to a secondary container cluster + network. See notes 5 and 6. It shall be + present if the internal CP is associated + to a VNFC realized by one or a set of OS + containers and is connected to a + secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + certificateContentId: + description: > + Identifier(s) of the + "CertificateContent" structure that + provides the information of the + certificate(s) that this VNFC CP + instance uses. Shall be present when + using in delegation-mode. Otherwise + shall not be present. This attribute + shall be supported when delegation mode + in certificate management is applicable + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this VNFC + instance uses. Shall be present when using + in delegation-mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + vnfVirtualLinkResourceInfo: + description: > + Information about the virtualised network + resources used by the VLs of the VNF instance. + See note 6. + type: array + items: + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by an internal VL instance in a VNF + instance. + + Note: If only the value or the presence of + this attribute is changed in the + "VnfVirtualLinkResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires including + a related "AffectedVirtualLink" structure in the VNF LCM operation occurrence notifications or the + "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId shall + be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being + globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfLinkPorts: + description: > + Links ports of this VL. Shall be present + when the linkPort is used for external + connectivity by the VNF (refer to + VnfLinkPortInfo). May be present + otherwise. + type: array + items: + description: > + This type represents a link port of an + internal VL of a VNF. + + NOTE 1: Either cpInstanceId with + cpInstanceType set to "EXT_CP" or any + combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 + provides examples for configurations + where both vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" + is scoped by the value of + "vimConnectionId" in the + "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + virtualStorageResourceInfo: + description: > + Information on the virtualised storage + resource(s) used as storage for the VNF + instance. + type: array + items: + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. + + Note: If only the value or the presence of + this attribute is changed in the + "VirtualStorageResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires + including a related "AffectedVirtualStorage" structure in the VNF LCM operation occurrence + notifications or the "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - virtualStorageDescId + - storageResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId shall + be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being + globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + mcioInfo: + description: > + Information on the MCIO(s) representing VNFC + instance(s) realized by one or a set of OS + containers and created from the same VDU for the + VNF instance. + type: array + items: + description: > + This type provides information about an MCIO + representing the set of VNFC instances + realized by one or a set of OS containers + which have been created based on the same VDU. + Within the CISM, an MCIO controller monitors + the actual state of an MCIO representing the + set of VNFC instances realized by one or a + set of OS containers and compare it to the + desired state For an MCIO related to a VDU + that has the attribute + isNumOfInstancesClusterBased set to FALSE the + desired state is specified in the respective + declarative descriptor. For an MCIO related + to a VDU that has the attribute + isNumOfInstancesClusterBased set to TRUE, the + desired state is determined by the number of + CIS-nodes in the cluster that fulfil the VDU + requirements.as specified in the respective + declarative descriptor. It triggers actions + toward the CIS to align the actual to the + desired state. Monitoring the actual state + includes monitoring the number of MCIO + instances available at any specific point in + time. In addition, an MCIO controller + maintains properties and runtime information + on the MCIO instances which have been created + based on the same VDU. The McioInfo data + structure provides the runtime information on + the MCIOs obtained from the MCIO controller. + + NOTE: There are different types of MCIOs. The + set of VNFC instances based on the same VDU is + represented + by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type + of MCIO, e.g. a POD. + + Runtime information of the set of OS + containers realizing an individual VNFC + instance is not part of the McioInfo data + structure; such runtime information is + provided in the ResourceHandle data structure + referenced from the VnfcResourceInfo. The + McioInfo does not provide runtime information + of a constituent VNFC instance created based + on a specific VDU. + + NOTE 1: The type of MCIO as specified in the + declarative descriptor of the MCIO, and that + can be read from + the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the + “kind” property of the declarative descriptor. + NOTE 2: If the attribute additionalInfo is + present, it may contain runtime information on + the actual and + desired state of the MCIO(s). + NOTE 3: When the container infrastructure + service is a Kubernetes® instance, the mcioId + is the combined + values from the kind and name fields of the Kubernetes resource object, separated by a slash. + Example: "Deployment/abcd". + NOTE 4: When the container infrastructure + service is a Kubernetes® instance, the + mcioName is the name + field of the resource object. + type: object + required: + - mcioId + - mcioName + - mcioNamespace + - vduId + - cismId + - mcioType + - desiredInstances + - availableInstances + properties: + mcioId: + description: > + An identifier with the intention of being + globally unique. + type: string + mcioName: + description: > + Human readable name of this MCIO. See note + 4. + type: string + mcioNamespace: + description: | + Namespace of this MCIO. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cismId: + description: > + An identifier with the intention of being + globally unique. + type: string + mcioType: + description: > + The type of MCIO. Specific values, their + semantics and associated MCIO types are + defined in clause 5.5.4.9. Additional + values are also permitted. See note 1. + type: string + enum: + - Deployment + - Statefulset + - DaemonSet + desiredInstances: + description: | + Number of desired MCIO instances. + type: integer + availableInstances: + description: | + Number of available MCIO instances. + type: integer + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this MCIO + instance uses. Shall be present when using + in delegation mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + vnfPaasServiceInfo: + description: > + Information on the PaaS Services assigned and + used by the VNF instance. + type: array + items: + description: > + This type provides input information about a + PaaS Service that is used by a VNF instance. + The PaasServiceInfo is comprised of various + sets of information. Some information comes + from the VNFD, other information comes from + the PaaS Service assets provided by the NFVO + to the VNFM, and other information is provided + at runtime information about the usage of the + PaaS Service. + type: object + required: + - id + - paasServiceId + - paasServiceType + - paasServiceRequestId + - paasServiceHandle + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being + globally unique. + type: string + paasServiceType: + description: >- + The type of PaaS Service. The value of + this attribute is expected to be matched + against values of the registered PaaS + Services in the PSR. + type: string + paasServiceVersion: + description: | + A version. + type: string + paasServiceRequestId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + paasServiceHandle: + description: > + This type provides information enabling + the access and use of the PaaS Service by + the VNF instance. The type and format of + the handle depends on the form that the + PaaS Service is formed. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + indicators: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + instantiate: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + terminate: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scale: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scaleToLevel: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeFlavour: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + heal: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + operate: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeExtConn: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + createSnapshot: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + revertToSnapshot: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeCurrentVnfPkg: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperationLinks: + description: > + Links to the most recent LCM operation occurrences + related to this resource. See note 9. + type: object + properties: + recentVnfLcmOperation: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmInstantiation: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScale: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScaleToLevel: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeFlavour: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmTerminate: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmHeal: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperate: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeExtConn: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmModifyInfo: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmCreateSnapshot: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmRevertToSnapshot: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeVnfPkg: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmSelectDplMods: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfcSnapshots: + description: > + Information about VNFC snapshots constituting this VNF + snapshot. + type: array + items: + description: "This type represents a VNFC snapshot.\nNOTE 1:\tThe identifier of the compute snapshot resource is assigned during creation of a VNFC snapshot \n being returned from the VIM as output data in the response message of the individual resource \n operations. This attribute shall only be present for a VNFC snapshot that has been newly created \n by the VNFM as a result of the \"Create VNF snapshot task\".\nNOTE 2:\tThe identifier of the storage snapshot resource is assigned during creation of a VNFC snapshot being \n returned from the VIM as output data in the response message of the individual resource operations. \n This attribute shall only be present for a VNFC snapshot with an associated storage resource and that \n has been newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n" + type: object + required: + - id + - vnfcInstanceId + - triggeredAt + - vnfcResourceId + properties: + id: + description: > + An identifier that is unique within a limited + local scope other than above listed identifiers, + such as within a complex data structure or within + a request-response pair. Representation: string of + variable length. + type: string + vnfcInstanceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + creationStartedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + creationFinishedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + vnfcResourceInfoId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + computeSnapshotResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + storageSnapshotResources: + description: > + Mapping of the storage resources associated to the + VNFC with the storage snapshot resources. + type: array + items: + type: object + required: + - storageResourceId + properties: + storageResourceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + storageSnapshotResource: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + userDefinedData: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + vnfStateSnapshotInfo: + description: > + This type represents information about VNF-specific + state snapshot data. + type: object + required: + - checksum + - isEncrypted + properties: + checksum: + description: | + Cheksum description + type: string + isEncrypted: + description: > + The Boolean is a data type having two values (true + and false). + type: boolean + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + userDefinedData: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfStateSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + takenFrom: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualVnfSnapshot.Get.200: + description: > + 200 OK + + + Shall be returned when information about an individual VNF snapshot was + read successfully. + + The response body shall contain a representation of the "Individual VNF + snapshot" resource, + + as defined in clause 5.5.2.22. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + ETag: + description: > + Used to provide the current entity-tag for the selected resource + representation. It can be sent in "200 OK", "201 Created" and "204 + No Content" responses. + style: simple + schema: + type: string + Last-Modified: + description: > + Used to provide a timestamp indicating the date and time at which + the server believes the selected resource representation was last + modified. It can be sent in "200 OK", "201 Created" and "204 No + Content" responses. + style: simple + schema: + type: string + format: date-time + content: + application/json: + schema: + type: array + items: + description: | + This type represents an "Individual VNF snapshot" resource. + type: object + required: + - id + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfSnapshotPkgId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfSnapshot: + description: | + This type represents a VNF snapshot. + type: object + required: + - id + - vnfInstanceId + - triggeredAt + - vnfdId + - vnfInfo + - vnfcSnapshots + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceId: + description: > + An identifier with the intention of being globally + unique. + type: string + creationStartedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + creationFinishedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstance: + description: "This type represents a VNF instance.\nNOTE:\tClause B.3.2 provides examples illustrating the relationship among the different run-time \n information elements (CP, VL and link ports) used to represent the connectivity of a VNF.\n\nNOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist between \n the previous and the newly referred VNF package, i.e. when the new VNFD is changed with \n respect to the previous VNFD in other aspects than merely referencing to other VNF software \n images. In order to avoid misalignment of the VnfInstance with the current VNF's on-boarded \n VNF Package, the values of attributes in the VnfInstance that have corresponding attributes \n in the VNFD shall be kept in sync with the values in the VNFD.\nNOTE 2:\tETSI GS NFV-SOL 001 [14] specifies the structure and format of the VNFD based on TOSCA specifications. NOTE 3:\tVNF configurable properties are sometimes also referred to as configuration parameters applicable \n to a VNF. Some of these are set prior to instantiation and cannot be modified if the VNF is instantiated, \n some are set prior to instantiation (are part of initial configuration) and can be modified later, \n and others can be set only after instantiation. The applicability of certain configuration may \n depend on the VNF and the required operation of the VNF at a certain point in time.\nNOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes \n of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared in the VNFD with a defined \n initial value. The defined initial values can be declared in the VNFD, and/or, in case of \"metadata\", \n obtained from the \"CreateVnfRequest\" structure. Child attributes of \"vnfConfigurableProperties\", \n \"metadata\" and \"extensions\" that have no defined initial value shall not be created, in order to be \n consistent with the semantics of the JSON Merge Patch method (see IETF RFC 7396) that interprets null \n values as deletion request.\nNOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a \n multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same \n VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed \n multi-site VL instance (refer to clause 5.5.3.3).\nNOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity, they shall \n not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\nNOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing \n the trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\nNOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the \n VNF LCM operation explicitly indicates the scale level for the aspect.\nNOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n" + type: object + required: + - id + - vnfdId + - vnfProvider + - vnfProductName + - vnfSoftwareVersion + - vnfdVersion + - instantiationState + - _links + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceName: + description: > + Name of the VNF instance. This attribute can be + modified with the PATCH method. + type: string + vnfInstanceDescription: + description: > + Human-readable description of the VNF instance. This + attribute can be modified with the PATCH method. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProvider: + description: > + Provider of the VNF and the VNFD. The value is + copied from the VNFD. + type: string + vnfProductName: + description: > + Name to identify the VNF Product. The value is + copied from the VNFD. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + vimConnectionInfo: + description: > + Information about VIM or CISM connections to be used + for managing the resources for the VNF instance. The + keys of the map, each of which identifies + information about a particular VIM connection, are + managed by the NFVO and referenced from other data + structures via the "vimConnectionId" attribute. This + attribute shall only be supported and present if - + the resources of at least of the VNFCs are managed + by a VIM and VNF-related resource management in + direct mode is applicable. - the resources of at + least of the VNFCs are managed by a CISM. This + attribute can be modified with the PATCH method. If + VIM connection information is provisioned to the + VNFM by means outside the scope of the present + document, the information in the "vimConnectionInfo" + attribute provides necessary information for binding + the VnfInstance representing the "Individual VNF + instance" to the applicable VIM connection + information used to perform resource management for + the VNF instance. See also the definition of the + "VimConnectionInfo" in clause 4.4.1.6. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being + globally unique. + type: string + vimType: + description: > + Discriminator for the different types of the + VIM information. The value of this attribute + determines the structure of the + "interfaceInfo" and "accessInfo" attributes, + based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values + is expected to change over time as new types + or versions of VIMs become available. The ETSI + NFV registry of VIM-related information + provides access to information about + VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The + structure of the registry is defined in annex + C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + extra: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + cirConnectionInfo: + description: > + Information about the CIR connection for managing OS + container images for the VNF instance. Shall be + present when all or part of the VNF is realized by a + set of OS containers and shall be absent otherwise. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being + globally unique. + type: string + vimType: + description: > + Discriminator for the different types of the + VIM information. The value of this attribute + determines the structure of the + "interfaceInfo" and "accessInfo" attributes, + based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values + is expected to change over time as new types + or versions of VIMs become available. The ETSI + NFV registry of VIM-related information + provides access to information about + VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The + structure of the registry is defined in annex + C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + extra: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + mciopRepositoryInfo: + description: > + Information about the MCIOP repository for the VNF + instance. Shall be present when all or part of the + VNF is realized by a set of OS containers and shall + be absent otherwise. See note 1. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being + globally unique. + type: string + vimType: + description: > + Discriminator for the different types of the + VIM information. The value of this attribute + determines the structure of the + "interfaceInfo" and "accessInfo" attributes, + based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values + is expected to change over time as new types + or versions of VIMs become available. The ETSI + NFV registry of VIM-related information + provides access to information about + VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The + structure of the registry is defined in annex + C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + extra: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + certificateInfo: + description: > + This type provides input information related to + certificate and certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + certificateConfigurationInfo: + description: > + This type provides input information related to + certificate management. + type: object + required: + - securityPolicy + properties: + certificateBaseProfile: + description: Information for certificate profile. + type: array + items: + description: > + NOTE: At least one overriding attributes + shall be present, otherwise shall be + absent. + + This type provides input information to + override certificate base profile for + certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + issuer: + description: Issuer of certificates. See note. + type: string + issuerUniqueIdentifier: + description: > + An identifier with the intention of + being globally unique. + type: string + subject: + description: > + This type provides input information + related to the subject of the + certificate. + + NOTE: At least one overriding attributes + shall be present, otherwise shall be + absent. + type: object + properties: + commonName: + description: > + Information of the certification target + subject FQDN. Can be set empty when this + certificate is used for encrypted + communication using IP address. See + note. + type: string + organization: + description: >- + Information of the certification target + subject Organization. See note. + type: string + country: + description: >- + Information of the certification target + subject Country. See note. + type: string + state: + description: >- + Information of the certification target + subject State. See note. + type: string + locality: + description: >- + Information of the certification target + subject Locality. See note. + type: string + emailAddress: + description: >- + Information of the certification contact + email address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of + being globally unique. + type: string + basicConstraints: + description: >- + Basic constraints of certificates. See + note. + type: string + issuerAltName: + description: >- + Alternative name of issuer of + certificates in this NS. See note. + type: array + items: + type: string + subjectAltName: + description: > + Alternative name of subject of + certificates. Shall be present when this + certificate is used for encrypted + communication using IP address and + subjectAltName attribute of + CertificateBaseProfile in + CertificateDesc of VNFD is empty (see + ETSI GS NFV-IFA 011 [14], clause + 7.1.19.4). See note. + type: array + items: + type: string + nameConstraints: + description: >- + Name constraints of certificates. See + note. + type: array + items: + type: string + securityPolicy: + description: >- + Information for security policy to be + satisfied for certificate. + type: array + items: + description: > + This type provides input information + related to security policy for certificate + management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + maxValidityPeriod: + description: >- + Allowed max validity period for + certificates. + type: number + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: number + delegationSupportedCertificateManagements: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + cmfInfo: + description: > + This type provides input information related + to CMF for certificate management. + type: object + required: + - id + - endPoint + - supportedProtocol + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + endPoint: + description: End point of CMF instance. + type: object + properties: + 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 + link: + description: > + This type represents a link to a + resource using an absolute URI. + type: object + required: + - href + properties: + href: + description: > + String formatted according to IETF RFC + 3986. + type: string + supportedProtocol: + description: Supported protocols by CMF instance. + type: array + items: + description: Supported protocol by CMF instance. + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + certificateChain: + description: >- + Certificate chain that this CMF + provides. + type: array + items: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + certificateContents: + description: > + Information for contents of issued certificates. + The information contained in this attribute may + be updated over time during the VNF LCM, e.g., + certificate(s) renewal. + type: array + items: + description: > + This type provides input information related + to certificate content. + + NOTE: The CertificateDesc data type is defined + in clause 7.1.19.2 of ETSI GS NFV IFA 011 + [10]. + type: object + required: + - id + - certificateDescId + - certificateType + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + certificateDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + certificateType: + description: Type of this certificate. + type: string + enum: + - VNFCI_CERT + - VNFOAM_CERT + supportedCertificateManagements: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + version: + description: | + A version. + type: string + serialNumber: + description: Serial number of this certificate. + type: integer + signatureAlgorithm: + description: Algorithm of this certificate's signature. + type: string + issuer: + description: Issuer of this certificate. + type: string + notBefore: + description: > + Date-time stamp. Representation: String + formatted according to IETF RFC 3339. + type: string + format: date-time + notAfter: + description: > + Date-time stamp. Representation: String + formatted according to IETF RFC 3339. + type: string + format: date-time + subject: + description: Subject of this certificate. + type: string + publicKeyAlgorithm: + description: >- + Algorithm of this certificate's public + key. + type: string + publicKey: + description: Public key of this certificate. + type: string + certificateExtensions: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + instantiationState: + description: > + The instantiation state of the VNF. Permitted + values: - NOT_INSTANTIATED: The VNF instance is + terminated or not instantiated. - INSTANTIATED: The + VNF instance is instantiated. + type: string + enum: + - NOT_INSTANTIATED + - INSTANTIATED + instantiatedVnfInfo: + description: > + Information specific to an instantiated VNF + instance. This attribute shall be present if the + instantiateState attribute value is INSTANTIATED. + type: object + required: + - flavourId + - vnfState + properties: + flavourId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfState: + description: > + STARTED: The VNF instance is up and running. + STOPPED: The VNF instance has been shut down. + type: string + enum: + - STARTED + - STOPPED + vnfPowerState: + description: > + This type represents information about the power + state of a VNF instance. + type: object + required: + - powerProfileId + - name + properties: + powerProfileId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + name: + description: > + Name of the power profile as provided in the + VNFD. + type: string + powerConsumptionInfo: + description: > + This type represents information about + estimated power consumption of the resources + associated with the power profile, as + provided in the VNFD. + type: object + required: + - minPowerConsumption + - maxPowerConsumption + - averagePowerConsumption + properties: + minPowerConsumption: + description: > + Minimum power consumption of this power + profile. Unit is KW/h. + type: integer + maxPowerConsumption: + description: > + Maximum power consumption of this power + profile. Unit is KW/h. + type: integer + averagePowerConsumption: + description: > + Average power consumption of this power + profile. Unit is KW/h. + type: integer + scaleStatus: + description: > + Scale status of the VNF, one entry per aspect. + Represents for every scaling aspect how "big" + the VNF has been scaled w.r.t. that aspect. + + This attribute shall be present if the VNF + supports scaling. See clause B.2 for an + explanation of VNF scaling. + + For an aspect that has not been deployed because + the related deployableModule has not been + selected, it indicates the scale level that has + been requested in the instantiation or in a + scaling operation, or, if none has been + requested in any of them, the scale level + applicable to the aspect based on the default + instantiation level. See note 8. + type: array + items: + description: > + This type represents the scale level of a VNF + instance related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being + globally unique. + type: string + maxScaleLevels: + description: > + Maximum allowed scale levels of the VNF, one + entry per aspect. This attribute shall be + present if the VNF supports scaling. + type: array + items: + description: > + This type represents the scale level of a VNF + instance related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being + globally unique. + type: string + selectedDeployableModule: + description: > + References a currently selected deployable + module, as defined in the VNFD, that has + already completed the instantiation of its + VNFCs. + type: array + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + resourceCapacityDefinition: + description: > + Shows current values of VDU attributes related + to resource capacity, if different to the + default values from the VNFD, as indicated in + the (one or more) request(s) of all completed + VNF LCM operation(s) that contain this + attribute. If an attribute value has been + modified multiple times, only the last value is + shown. The values indicated in this attribute + are applicable to all VNFC instances based on + the VDU to which the resourceCapacityDefinition + is related. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes. + + * NOTE: Resource definitions not related to a + VDU are not considered in this version of the + present document. + type: object + required: + - type + properties: + tag: + description: > + Tag assigned by the issuer of a VNF LCM + operation request that contains this data + type with values to be applied to a VDU. + It is used for tracking purposes. + + The tag is preserved in the run time + record as long as at least one value of + the capacity related attributes + associated with that tag is still valid, + i.e., it has not been modified by a later + VNF LCM operation request. + + At most one tag can be included when the + data type is used in a VNF LCM operation + request. + + When the data type is used in the + VnfInstance data type it may contain + multiple tags, namely those provided in + VNF LCM requests, if at least one of the + values provided in that request associated + to that tag is still applicable in the + VNFCs created from this VDU, i.e., it has + not been modified by a later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: > + Type of the resource definition + referenced. + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + osContainerDescData: + description: > + Indicates values for resource capacity + related attributes in an OsContainerDesc. + It shall be present when the attribute + 'type' indicates OSCONTAINER and absent + otherwise. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes of an + OsContainer resource. + + * NOTE: At least one of the attributes + shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for + the container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for + the container expressed in the same + units as specified in the + requested_memory_resources_valid_values + property in VNFD (clause 6.8.12 in ETSI + GS NFV-SOL 001 [14]) for this container + descriptor. See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources + of the type indicated in the key. The + key is a string that identifies an + extended resource indicated in the + extended_resource_requests property in + the VNFD (clause 6.8.12 in ETSI GS + NFV-SOL 001 [14]) for this container + descriptor. The value is an integer that + indicates the required amount for a + particular extended resource. See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container + can maximally use in milli-CPU. See + note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required + for all the hugepages of the size + indicated in the key. The key is a + string and corresponds to one of the + values of the hugepage sizes indicated + in the huge_pages_resources property in + the VNFD (clause 6.8.12 in ETSI GS + NFV-SOL 001 [14]) for this container + descriptor. The value is a number that + indicates the required total size + expressed in the same units as in the + huge_pages_resource property in the VNFD + (clause 6.8.12 in ETSI GS NFV-SOL 001 + [14]) that indicates the valid values + for required total size for the + particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power + state configuration data for the virtual + compute or OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU + cores are requested to be allocated to + logical CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states + of virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on + core utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for + capacity related VDU attributes of the + virtual compute resource of a VM. + + * NOTE: At least one of the attributes + shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required + for all the hugepages of the size + indicated in the key. The key is a + string and corresponds to one of the + values of the hugepage sizes indicated + in the huge_pages_requirements property + in the VNFD (clause 6.2.7.2 in ETSI GS + NFV-SOL 001 [14]) for this virtual + compute descriptor. The value is a + numberthat indicates the required total + size expressed in the same units as in + the huge_pages_requirements property in + the VNFD (clause 6.2.7.2 in ETSI GS + NFV-SOL 001 [14]) that indicates the + valid vaues for required total size for + the particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power + state configuration data for the virtual + compute or OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU + cores are requested to be allocated to + logical CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states + of virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on + core utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size + related attribute in an + VirtualStorageDesc. It shall be present + when the attribute 'type' indicates + STORAGE and absent otherwise. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes of the + virtual storage resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + extCpInfo: + description: > + Information about the external CPs exposed by + the VNF instance. When trunking is enabled, the + list of entries includes both, external CPs + corresponding to parent ports of a trunk, and + external CPs associated to sub-ports of a + trunk.See note 7. + type: array + items: + description: "This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n" + type: object + required: + - id + - cpdId + - cpConfigId + - cpProtocolInfo + oneOf: + - required: + - associatedVnfcCpId + - required: + - associatedVipCpId + - required: + - associatedVnfVirtualLinkId + properties: + id: + 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 + cpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolInfo: + description: | + Network protocol information for this CP. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + extLinkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + associatedVnfcCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVipCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVirtualCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVnfVirtualLinkId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceInfo” + structure that provides the specification + of the interface to attach the connection + point to a secondary container cluster + network. See notes 3 and 4. + + It shall be present if the external CP is + associated to a VNFC realized by one or a + set of OS containers and is connected to a + secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this VNF CP + instance uses. Shall be present when using + in delegation-mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + cpSecurityGroupInfo: + description: > + This type provides the list of active + security group rules applied to an + external CP instance. The type identifies + which "SecurityGroupRule" specified in the + VNFD are activated and the values of its + attributes. + type: object + required: + - securityGroupRuleId + - etherType + - protocol + - portRangeMin + - portRangeMax + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + description: + description: > + Human readable description of the + security group rule. + type: string + etherType: + description: > + Indicates the protocol carried over the + Ethernet layer. Permitted values: IPV4, + IPV6. + type: string + enum: + - IPV4 + - IPV6 + protocol: + description: > + Indicates the protocol carried over the + IP layer. Permitted values: any protocol + defined in the IANA protocol registry + (refer to clause 9.10.1.2 ofd ETSI GS + NFV-SOL 001 for further information). + type: string + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. + type: integer + vipCpInfo: + description: > + VIP CPs that are part of the VNF instance. Shall + be present when that particular VIP CP of the + VNFC instance is associated to an external CP of + the VNF instance. May be present otherwise. + type: array + minItems: 1 + items: + description: "This type provides information related to virtual IP (VIP) CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n" + type: object + required: + - cpInstanceId + - cpdId + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There + shall be one cpProtocolInfo for layer 3. + There may be one cpProtocolInfo for layer + 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + associatedVnfcCpIds: + description: > + Identifiers of the VnfcCps that share the + virtual IP address allocated to the VIP CP + instance. See note. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + virtualCpInfo: + description: > + Virtual CPs that are part of the VNF instance. + Shall be present when a particular Virtual CP is + associated to an external CP of the VNF + instance. May be present otherwise. + type: array + items: + description: > + This type provides information related to a + virtual CP instance of a VNF. + + NOTE 1: A consumer of the VNF LCM interface + can learn the actual VNFC instances + implementing the service + accessible via the virtual CP instance by querying the "vnfcResourceInfo" from the "InstantiatedVnfInfo" + and filtering by corresponding "vduIds" values. + NOTE 2: The information can be omitted because + it is already available as part of the + external CP information in the + VnfExtCpInfo structure. + type: object + required: + - cpInstanceId + - cpdId + - resourceHandle + - vduIds + properties: + cpInstanceId: + 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 + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId shall + be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There + shall be one cpProtocolInfo for each layer + protocol supported. This attribute may be + omitted if the virtual CP is exposed as an + external CP. See note 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vduIds: + description: > + Reference to the VDU(s) which implement + the service accessible via the virtual CP + instance. See note 1. + type: array + minItems: 1 + items: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + additionalServiceInfo: + description: > + Additional service identification + information of the virtual CP instance. + type: array + items: + description: > + This type provides additional service + information of the virtual CP instance + used to expose properties of the + virtual CP to NFV-MANO. + + NOTE: This attribute shall only be + present if additional information is + needed to identify the service + termination within the VNF, such as for example a URL path information in an HTTP request required + to allow a single virtual CP IP address to be used for several HTTP based services that use the + same port number. + type: object + required: + - portInfo + properties: + portInfo: + description: > + Service port numbers exposed by the + virtual CP instance. + minItems: 1 + type: array + items: + description: > + This type describes the service + identifying port properties exposed by + the virtual CP instance. + type: object + required: + - name + - port + - portConfigurable + properties: + name: + description: > + The name of the port exposed by the + virtual CP instance. + type: string + protocol: + description: > + The L4 protocol for this port exposed by + the virtual CP instance. + + Permitted values: - TCP - UDP - SCTP + type: string + enum: + - TCP + - UDP + - SCTP + port: + description: > + The L4 port number exposed by the + virtual CP instance. + type: integer + portConfigurable: + description: > + The Boolean is a data type having two + values (true and false). + type: boolean + serviceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + extVirtualLinkInfo: + description: > + Information about the external VLs the VNF + instance is connected to. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId shall + be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the + current CP configuration information for + the connection of external CPs to the + external virtual link. See note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be + configured on the CP instances created + from the respective CPD. + + The key of the map which identifies the + individual VnfExtCpConfig entries is of + type "IdentifierInVnf" and is managed by + the NFVO. + + The entries shall be applied by the VNFM + according to the rules of JSON Merge + Patch (see IETF RFC 7396). See notes 2, + 3, 4, 5, 6. In case of deleting an + external CP, the list of instances to be + deleted. + type: object + additionalProperties: + description: > + This type represents an externally + provided link port, or a network + attachment definition resource of + secondary container cluster network, or + network address information per instance + of an external connection point. In the + case of VM-based deployment of the VNFC + exposing the external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based + deployment of the VNFC exposing the + external CP, the VNFM shall use the + network attachment definition resource + of secondary container cluster network + when connecting the CP to the external + VL. + + * NOTE 1: The following conditions apply + to the attributes "linkPortId" and + "cpProtocolData" for an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply + to the attributes “netAttDefResourceId” + and “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is + only applicable for specific cases where + more than one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but + not both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of + being globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create + a dedicated link port for the external + CP. If set to True, the VNFM shall + create a link port. If set to False, the + VNFM shall not create a link port. This + attribute is only applicable for + external CP instances without a floating + IP address that expose a VIP CP instance + for which a dedicated IP address is + allocated. It shall be present in that + case and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceData” structure that + provides the specification of the + interface to attach the external CP to a + secondary container cluster network. It + is only applicable if the external CP is + connected or to be connected to a + secondary container cluster network. It + shall not be present if the external CP + is related to a virtual network not + categorized as secondary container + cluster network. See notes 2, 3 and 4. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects + the CP to a VL and the domain names for + the external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security + groups. The parameters identify which + "SecurityGroupRule" specified in the + VNFD is activated/deactivated and for an + activated security group rule the values + of attributes defined in the VNFD that + can be overriden such as "portRangeMin" + and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extNetAttDefResource: + description: > + Network attachment definition resources + that provide the specification of the + interface to attach connection points to + this VL. + type: array + items: + description: > + This type contains information related + to a network attachment definition + resource that provides the + specification of the interface used to + connect one or multiple connection + points to a secondary container cluster + network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of + being globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated + to this network attachment definition + resource. Shall be present when the + network attachment definition resource + is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to + this network attachment definition + resource. May be present when the + network attachment definition resource + is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + extManagedVirtualLinkInfo: + description: > + Information about the externally-managed + internal VLs of the VNF instance. See notes 5 + and 6. + type: array + items: + description: > + This type provides information about an + externally-managed virtual link. Note: Both + "vnfLinkPort" and "vnfNetAttDefResource" + attributes can be present in an + "ExtManagedVirtualLinkInfo" to + indicate that a single internal virtual link is providing connectivity for both VM-based and container-based + VNFCs. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId shall + be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + vnfLinkPorts: + description: | + Link ports of this VL. See note. + type: array + items: + description: > + This type represents a link port of an + internal VL of a VNF. + + NOTE 1: Either cpInstanceId with + cpInstanceType set to "EXT_CP" or any + combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 + provides examples for configurations + where both vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" + is scoped by the value of + "vimConnectionId" in the + "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vnfNetAttDefResource: + description: > + Network attachment definition resources + that provide the specification of the + interface to attach connection points to + this VL. See note. + type: array + items: + description: > + This type contains information related + to a network attachment definition + resource that provides the + specification of the interface used to + connect one or multiple connection + points to a secondary container cluster + network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of + being globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated + to this network attachment definition + resource. Shall be present when the + network attachment definition resource + is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to + this network attachment definition + resource. May be present when the + network attachment definition resource + is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + extManagedMultisiteVirtualLinkId: + description: > + An identifier with the intention of being + globally unique. + type: string + routingResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId shall + be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + monitoringParameters: + description: | + Active monitoring parameters. + type: array + items: + description: > + This type represents a monitoring parameter + that is tracked by the VNFM, + type: object + required: + - id + - performanceMetric + properties: + id: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + name: + description: > + Human readable name of the monitoring + parameter, as defined in the VNFD. + type: string + performanceMetric: + description: > + Performance metric that is monitored. This + attribute shall contain the related + "Measurement Name" value as defined in + clause 7.2 of ETSI GS NFV-IFA 027. + type: string + localizationLanguage: + description: > + Information about localization language of the + VNF (includes e.g. strings in the VNFD). The + localization languages supported by a VNF can be + declared in the VNFD, and localization language + selection can take place at instantiation time. + The value shall comply with the format defined + in IETF RFC 5646. + type: string + vnfcResourceInfo: + description: > + Information about the virtualised compute and + storage resources used by the VNFCs of the VNF + instance. + type: array + items: + description: "This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure of\n information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n a) For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n b) For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\nNOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on \n TOSCA specifications.\nNOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an \n internal VL that exposes an external CP. A VNFC CP is \"exposed as\" an external \n CP if it is connected directly to an external VL.\nNOTE 3:\tThe information can be omitted because it is already available as part of the \n external CP information.\nNOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\"\n structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVnfc\" structure in the VNF LCM operation occurrence notifications\n or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\nNOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment\n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. \nNOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n" + type: object + required: + - id + - vduId + - computeResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId shall + be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being + globally unique. + type: string + storageResourceIds: + description: > + References to the VirtualStorage resources + or references to Storage MCIOs. The value + refers to a VirtualStorageResourceInfo + item in the VnfInstance. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfcCpInfo: + description: > + CPs of the VNFC instance. Shall be present + when that particular CP of the VNFC + instance is exposed as an external CP of + the VNF instance or is connected to an + external CP of the VNF instance. See note + 2. May be present otherwise. See note 7. + type: array + items: + type: object + required: + - id + - cpdId + properties: + id: + 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 + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpProtocolInfo: + description: > + Network protocol information for this + CP. May be omitted if the VNFC CP is + exposed as an external CP. See note 3. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + parentCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceInfo” structure that + provides the specification of the + interface to attach the connection point + to a secondary container cluster + network. See notes 5 and 6. It shall be + present if the internal CP is associated + to a VNFC realized by one or a set of OS + containers and is connected to a + secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + certificateContentId: + description: > + Identifier(s) of the + "CertificateContent" structure that + provides the information of the + certificate(s) that this VNFC CP + instance uses. Shall be present when + using in delegation-mode. Otherwise + shall not be present. This attribute + shall be supported when delegation mode + in certificate management is applicable + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this VNFC + instance uses. Shall be present when using + in delegation-mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + vnfVirtualLinkResourceInfo: + description: > + Information about the virtualised network + resources used by the VLs of the VNF instance. + See note 6. + type: array + items: + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by an internal VL instance in a VNF + instance. + + Note: If only the value or the presence of + this attribute is changed in the + "VnfVirtualLinkResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires including + a related "AffectedVirtualLink" structure in the VNF LCM operation occurrence notifications or the + "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId shall + be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being + globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfLinkPorts: + description: > + Links ports of this VL. Shall be present + when the linkPort is used for external + connectivity by the VNF (refer to + VnfLinkPortInfo). May be present + otherwise. + type: array + items: + description: > + This type represents a link port of an + internal VL of a VNF. + + NOTE 1: Either cpInstanceId with + cpInstanceType set to "EXT_CP" or any + combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 + provides examples for configurations + where both vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" + is scoped by the value of + "vimConnectionId" in the + "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + virtualStorageResourceInfo: + description: > + Information on the virtualised storage + resource(s) used as storage for the VNF + instance. + type: array + items: + description: > + This type represents the information that + allows addressing a virtualised resource that + is used by a VNF instance. + + Note: If only the value or the presence of + this attribute is changed in the + "VirtualStorageResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires + including a related "AffectedVirtualStorage" structure in the VNF LCM operation occurrence + notifications or the "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - virtualStorageDescId + - storageResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId shall + be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being + globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + mcioInfo: + description: > + Information on the MCIO(s) representing VNFC + instance(s) realized by one or a set of OS + containers and created from the same VDU for the + VNF instance. + type: array + items: + description: > + This type provides information about an MCIO + representing the set of VNFC instances + realized by one or a set of OS containers + which have been created based on the same VDU. + Within the CISM, an MCIO controller monitors + the actual state of an MCIO representing the + set of VNFC instances realized by one or a + set of OS containers and compare it to the + desired state For an MCIO related to a VDU + that has the attribute + isNumOfInstancesClusterBased set to FALSE the + desired state is specified in the respective + declarative descriptor. For an MCIO related + to a VDU that has the attribute + isNumOfInstancesClusterBased set to TRUE, the + desired state is determined by the number of + CIS-nodes in the cluster that fulfil the VDU + requirements.as specified in the respective + declarative descriptor. It triggers actions + toward the CIS to align the actual to the + desired state. Monitoring the actual state + includes monitoring the number of MCIO + instances available at any specific point in + time. In addition, an MCIO controller + maintains properties and runtime information + on the MCIO instances which have been created + based on the same VDU. The McioInfo data + structure provides the runtime information on + the MCIOs obtained from the MCIO controller. + + NOTE: There are different types of MCIOs. The + set of VNFC instances based on the same VDU is + represented + by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type + of MCIO, e.g. a POD. + + Runtime information of the set of OS + containers realizing an individual VNFC + instance is not part of the McioInfo data + structure; such runtime information is + provided in the ResourceHandle data structure + referenced from the VnfcResourceInfo. The + McioInfo does not provide runtime information + of a constituent VNFC instance created based + on a specific VDU. + + NOTE 1: The type of MCIO as specified in the + declarative descriptor of the MCIO, and that + can be read from + the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the + “kind” property of the declarative descriptor. + NOTE 2: If the attribute additionalInfo is + present, it may contain runtime information on + the actual and + desired state of the MCIO(s). + NOTE 3: When the container infrastructure + service is a Kubernetes® instance, the mcioId + is the combined + values from the kind and name fields of the Kubernetes resource object, separated by a slash. + Example: "Deployment/abcd". + NOTE 4: When the container infrastructure + service is a Kubernetes® instance, the + mcioName is the name + field of the resource object. + type: object + required: + - mcioId + - mcioName + - mcioNamespace + - vduId + - cismId + - mcioType + - desiredInstances + - availableInstances + properties: + mcioId: + description: > + An identifier with the intention of being + globally unique. + type: string + mcioName: + description: > + Human readable name of this MCIO. See note + 4. + type: string + mcioNamespace: + description: | + Namespace of this MCIO. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cismId: + description: > + An identifier with the intention of being + globally unique. + type: string + mcioType: + description: > + The type of MCIO. Specific values, their + semantics and associated MCIO types are + defined in clause 5.5.4.9. Additional + values are also permitted. See note 1. + type: string + enum: + - Deployment + - Statefulset + - DaemonSet + desiredInstances: + description: | + Number of desired MCIO instances. + type: integer + availableInstances: + description: | + Number of available MCIO instances. + type: integer + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this MCIO + instance uses. Shall be present when using + in delegation mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + vnfPaasServiceInfo: + description: > + Information on the PaaS Services assigned and + used by the VNF instance. + type: array + items: + description: > + This type provides input information about a + PaaS Service that is used by a VNF instance. + The PaasServiceInfo is comprised of various + sets of information. Some information comes + from the VNFD, other information comes from + the PaaS Service assets provided by the NFVO + to the VNFM, and other information is provided + at runtime information about the usage of the + PaaS Service. + type: object + required: + - id + - paasServiceId + - paasServiceType + - paasServiceRequestId + - paasServiceHandle + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being + globally unique. + type: string + paasServiceType: + description: >- + The type of PaaS Service. The value of + this attribute is expected to be matched + against values of the registered PaaS + Services in the PSR. + type: string + paasServiceVersion: + description: | + A version. + type: string + paasServiceRequestId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + paasServiceHandle: + description: > + This type provides information enabling + the access and use of the PaaS Service by + the VNF instance. The type and format of + the handle depends on the form that the + PaaS Service is formed. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + indicators: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + instantiate: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + terminate: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scale: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scaleToLevel: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeFlavour: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + heal: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + operate: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeExtConn: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + createSnapshot: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + revertToSnapshot: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeCurrentVnfPkg: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperationLinks: + description: > + Links to the most recent LCM operation occurrences + related to this resource. See note 9. + type: object + properties: + recentVnfLcmOperation: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmInstantiation: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScale: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScaleToLevel: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeFlavour: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmTerminate: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmHeal: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperate: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeExtConn: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmModifyInfo: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmCreateSnapshot: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmRevertToSnapshot: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeVnfPkg: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmSelectDplMods: + description: > + This type represents a link to a resource using + an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfcSnapshots: + description: > + Information about VNFC snapshots constituting this VNF + snapshot. + type: array + items: + description: "This type represents a VNFC snapshot.\nNOTE 1:\tThe identifier of the compute snapshot resource is assigned during creation of a VNFC snapshot \n being returned from the VIM as output data in the response message of the individual resource \n operations. This attribute shall only be present for a VNFC snapshot that has been newly created \n by the VNFM as a result of the \"Create VNF snapshot task\".\nNOTE 2:\tThe identifier of the storage snapshot resource is assigned during creation of a VNFC snapshot being \n returned from the VIM as output data in the response message of the individual resource operations. \n This attribute shall only be present for a VNFC snapshot with an associated storage resource and that \n has been newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n" + type: object + required: + - id + - vnfcInstanceId + - triggeredAt + - vnfcResourceId + properties: + id: + description: > + An identifier that is unique within a limited + local scope other than above listed identifiers, + such as within a complex data structure or within + a request-response pair. Representation: string of + variable length. + type: string + vnfcInstanceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + creationStartedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + creationFinishedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + vnfcResourceInfoId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + computeSnapshotResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + storageSnapshotResources: + description: > + Mapping of the storage resources associated to the + VNFC with the storage snapshot resources. + type: array + items: + type: object + required: + - storageResourceId + properties: + storageResourceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + storageSnapshotResource: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + userDefinedData: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + vnfStateSnapshotInfo: + description: > + This type represents information about VNF-specific + state snapshot data. + type: object + required: + - checksum + - isEncrypted + properties: + checksum: + description: | + Cheksum description + type: string + isEncrypted: + description: > + The Boolean is a data type having two values (true + and false). + type: boolean + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + userDefinedData: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfStateSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + takenFrom: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualVnfSnapshot.Patch.200: + description: > + 200 OK + + + Shall be returned when the modification of VNF snapshot information has + been accepted and completed. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + ETag: + description: > + Used to provide the current entity-tag for the selected resource + representation. It can be sent in "200 OK", "201 Created" and "204 + No Content" responses. + style: simple + schema: + type: string + Last-Modified: + description: > + Used to provide a timestamp indicating the date and time at which + the server believes the selected resource representation was last + modified. It can be sent in "200 OK", "201 Created" and "204 No + Content" responses. + style: simple + schema: + type: string + format: date-time + content: + application/json: + schema: + description: > + This type represents attribute modifications that were performed + on an "Individual VNF snapshot" + + resource. The attributes that can be included consist of those + requested to be modified explicitly + + in the "VnfSnapshotInfoModificationRequest" data structure, and + additional attributes of the + + "VnfSnapshotInfo" data structure that were modified implicitly. + type: object + properties: + vnfSnapshotPkgId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfSnapshot: + description: | + This type represents a VNF snapshot. + type: object + required: + - id + - vnfInstanceId + - triggeredAt + - vnfdId + - vnfInfo + - vnfcSnapshots + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + creationStartedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + creationFinishedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfInstance: + description: "This type represents a VNF instance.\nNOTE:\tClause B.3.2 provides examples illustrating the relationship among the different run-time \n information elements (CP, VL and link ports) used to represent the connectivity of a VNF.\n\nNOTE 1:\tModifying the value of this attribute shall not be performed when conflicts exist between \n the previous and the newly referred VNF package, i.e. when the new VNFD is changed with \n respect to the previous VNFD in other aspects than merely referencing to other VNF software \n images. In order to avoid misalignment of the VnfInstance with the current VNF's on-boarded \n VNF Package, the values of attributes in the VnfInstance that have corresponding attributes \n in the VNFD shall be kept in sync with the values in the VNFD.\nNOTE 2:\tETSI GS NFV-SOL 001 [14] specifies the structure and format of the VNFD based on TOSCA specifications. NOTE 3:\tVNF configurable properties are sometimes also referred to as configuration parameters applicable \n to a VNF. Some of these are set prior to instantiation and cannot be modified if the VNF is instantiated, \n some are set prior to instantiation (are part of initial configuration) and can be modified later, \n and others can be set only after instantiation. The applicability of certain configuration may \n depend on the VNF and the required operation of the VNF at a certain point in time.\nNOTE 4:\tUpon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes \n of \"vnfConfigurableProperties\", \"metadata\" and \"extensions\" that were declared in the VNFD with a defined \n initial value. The defined initial values can be declared in the VNFD, and/or, in case of \"metadata\", \n obtained from the \"CreateVnfRequest\" structure. Child attributes of \"vnfConfigurableProperties\", \n \"metadata\" and \"extensions\" that have no defined initial value shall not be created, in order to be \n consistent with the semantics of the JSON Merge Patch method (see IETF RFC 7396) that interprets null \n values as deletion request.\nNOTE 5:\tIt is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a \n multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same \n VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed \n multi-site VL instance (refer to clause 5.5.3.3).\nNOTE 6:\tEven though externally-managed internal VLs are also used for VNF-internal connectivity, they shall \n not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\nNOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing \n the trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\nNOTE 8: For a scaling aspect whose related VNFCs have not been instantiated due to the selection of deployable \n modules, the “scaleStatus” indicates the scale level that would be applicable to the aspect if a VNF LCM \n operation changes the selected deployable modules and the related VNFCs are instantiated, unless the \n VNF LCM operation explicitly indicates the scale level for the aspect.\nNOTE 9: The recentVnfLcmOperationLinks attribute does not provide a complete historical record of LCM changes\n that a VNF instance experienced during its lifecycle. The information in this attribute should not be used to\n create a chronological order of events that cannot be inferred by looking only at the most recent operation\n occurrences due to potential gaps in timeline. This is because there can be many possible combination of\n LCM changes that a VNF may have gone through between two operation occurrences recorded in the\n recentVnfLcmOperationLinks attribute. For example, there can be many scaling related LCM changes since\n an individual VNF instance has been instantiated until the most recent scaling operation occurrence linked in\n the attribute. In another example, the most recent LCM operation occurrence related to instantiate VNF\n operation may be more recent than the one that caused the VNF instance to be terminated last time, which\n prevents the possibility to create a meaningful chronological timeline of VNF LCM events.\n" + type: object + required: + - id + - vnfdId + - vnfProvider + - vnfProductName + - vnfSoftwareVersion + - vnfdVersion + - instantiationState + - _links + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceName: + description: > + Name of the VNF instance. This attribute can be + modified with the PATCH method. + type: string + vnfInstanceDescription: + description: > + Human-readable description of the VNF instance. This + attribute can be modified with the PATCH method. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProvider: + description: > + Provider of the VNF and the VNFD. The value is copied + from the VNFD. + type: string + vnfProductName: + description: > + Name to identify the VNF Product. The value is copied + from the VNFD. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + vimConnectionInfo: + description: > + Information about VIM or CISM connections to be used + for managing the resources for the VNF instance. The + keys of the map, each of which identifies information + about a particular VIM connection, are managed by the + NFVO and referenced from other data structures via the + "vimConnectionId" attribute. This attribute shall only + be supported and present if - the resources of at + least of the VNFCs are managed by a VIM and + VNF-related resource management in direct mode is + applicable. - the resources of at least of the VNFCs + are managed by a CISM. This attribute can be modified + with the PATCH method. If VIM connection information + is provisioned to the VNFM by means outside the scope + of the present document, the information in the + "vimConnectionInfo" attribute provides necessary + information for binding the VnfInstance representing + the "Individual VNF instance" to the applicable VIM + connection information used to perform resource + management for the VNF instance. See also the + definition of the "VimConnectionInfo" in clause + 4.4.1.6. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being + globally unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute + determines the structure of the "interfaceInfo" + and "accessInfo" attributes, based on the type + of the VIM., CISM, CIR or MCIOP repository. The + set of permitted values is expected to change + over time as new types or versions of VIMs + become available. The ETSI NFV registry of + VIM-related information provides access to + information about VimConnectionInfo definitions + for various VIM, CISM, CIR or MCIOP repository + types. The structure of the registry is defined + in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + cirConnectionInfo: + description: > + Information about the CIR connection for managing OS + container images for the VNF instance. Shall be + present when all or part of the VNF is realized by a + set of OS containers and shall be absent otherwise. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being + globally unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute + determines the structure of the "interfaceInfo" + and "accessInfo" attributes, based on the type + of the VIM., CISM, CIR or MCIOP repository. The + set of permitted values is expected to change + over time as new types or versions of VIMs + become available. The ETSI NFV registry of + VIM-related information provides access to + information about VimConnectionInfo definitions + for various VIM, CISM, CIR or MCIOP repository + types. The structure of the registry is defined + in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + mciopRepositoryInfo: + description: > + Information about the MCIOP repository for the VNF + instance. Shall be present when all or part of the VNF + is realized by a set of OS containers and shall be + absent otherwise. See note 1. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being + globally unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute + determines the structure of the "interfaceInfo" + and "accessInfo" attributes, based on the type + of the VIM., CISM, CIR or MCIOP repository. The + set of permitted values is expected to change + over time as new types or versions of VIMs + become available. The ETSI NFV registry of + VIM-related information provides access to + information about VimConnectionInfo definitions + for various VIM, CISM, CIR or MCIOP repository + types. The structure of the registry is defined + in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + certificateInfo: + description: > + This type provides input information related to + certificate and certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + certificateConfigurationInfo: + description: > + This type provides input information related to + certificate management. + type: object + required: + - securityPolicy + properties: + certificateBaseProfile: + description: Information for certificate profile. + type: array + items: + description: > + NOTE: At least one overriding attributes + shall be present, otherwise shall be absent. + + This type provides input information to + override certificate base profile for + certificate management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + issuer: + description: Issuer of certificates. See note. + type: string + issuerUniqueIdentifier: + description: > + An identifier with the intention of + being globally unique. + type: string + subject: + description: > + This type provides input information + related to the subject of the + certificate. + + NOTE: At least one overriding attributes + shall be present, otherwise shall be + absent. + type: object + properties: + commonName: + description: > + Information of the certification target + subject FQDN. Can be set empty when this + certificate is used for encrypted + communication using IP address. See + note. + type: string + organization: + description: >- + Information of the certification target + subject Organization. See note. + type: string + country: + description: >- + Information of the certification target + subject Country. See note. + type: string + state: + description: >- + Information of the certification target + subject State. See note. + type: string + locality: + description: >- + Information of the certification target + subject Locality. See note. + type: string + emailAddress: + description: >- + Information of the certification contact + email address. See note. + type: string + subjectUniqueIdentifier: + description: > + An identifier with the intention of + being globally unique. + type: string + basicConstraints: + description: >- + Basic constraints of certificates. See + note. + type: string + issuerAltName: + description: >- + Alternative name of issuer of + certificates in this NS. See note. + type: array + items: + type: string + subjectAltName: + description: > + Alternative name of subject of + certificates. Shall be present when this + certificate is used for encrypted + communication using IP address and + subjectAltName attribute of + CertificateBaseProfile in + CertificateDesc of VNFD is empty (see + ETSI GS NFV-IFA 011 [14], clause + 7.1.19.4). See note. + type: array + items: + type: string + nameConstraints: + description: >- + Name constraints of certificates. See + note. + type: array + items: + type: string + securityPolicy: + description: >- + Information for security policy to be + satisfied for certificate. + type: array + items: + description: > + This type provides input information related + to security policy for certificate + management. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + maxValidityPeriod: + description: >- + Allowed max validity period for + certificates. + type: number + allowedAlgorithm: + description: Allowed signature algorithm. + type: string + minimumKeyLength: + description: Minimum key length for certificates. + type: number + delegationSupportedCertificateManagements: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + cmfInfo: + description: > + This type provides input information related + to CMF for certificate management. + type: object + required: + - id + - endPoint + - supportedProtocol + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + endPoint: + description: End point of CMF instance. + type: object + properties: + 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 + link: + description: > + This type represents a link to a + resource using an absolute URI. + type: object + required: + - href + properties: + href: + description: > + String formatted according to IETF RFC + 3986. + type: string + supportedProtocol: + description: Supported protocols by CMF instance. + type: array + items: + description: Supported protocol by CMF instance. + type: string + enum: + - CMP + - CMPv2 + - EST + - SCEP + certificateChain: + description: Certificate chain that this CMF provides. + type: array + items: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + certificateContents: + description: > + Information for contents of issued certificates. + The information contained in this attribute may be + updated over time during the VNF LCM, e.g., + certificate(s) renewal. + type: array + items: + description: > + This type provides input information related to + certificate content. + + NOTE: The CertificateDesc data type is defined + in clause 7.1.19.2 of ETSI GS NFV IFA 011 [10]. + type: object + required: + - id + - certificateDescId + - certificateType + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + certificateDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + certificateType: + description: Type of this certificate. + type: string + enum: + - VNFCI_CERT + - VNFOAM_CERT + supportedCertificateManagements: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + version: + description: | + A version. + type: string + serialNumber: + description: Serial number of this certificate. + type: integer + signatureAlgorithm: + description: Algorithm of this certificate's signature. + type: string + issuer: + description: Issuer of this certificate. + type: string + notBefore: + description: > + Date-time stamp. Representation: String + formatted according to IETF RFC 3339. + type: string + format: date-time + notAfter: + description: > + Date-time stamp. Representation: String + formatted according to IETF RFC 3339. + type: string + format: date-time + subject: + description: Subject of this certificate. + type: string + publicKeyAlgorithm: + description: Algorithm of this certificate's public key. + type: string + publicKey: + description: Public key of this certificate. + type: string + certificateExtensions: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + instantiationState: + description: > + The instantiation state of the VNF. Permitted values: + - NOT_INSTANTIATED: The VNF instance is terminated or + not instantiated. - INSTANTIATED: The VNF instance is + instantiated. + type: string + enum: + - NOT_INSTANTIATED + - INSTANTIATED + instantiatedVnfInfo: + description: > + Information specific to an instantiated VNF instance. + This attribute shall be present if the + instantiateState attribute value is INSTANTIATED. + type: object + required: + - flavourId + - vnfState + properties: + flavourId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfState: + description: > + STARTED: The VNF instance is up and running. + STOPPED: The VNF instance has been shut down. + type: string + enum: + - STARTED + - STOPPED + vnfPowerState: + description: > + This type represents information about the power + state of a VNF instance. + type: object + required: + - powerProfileId + - name + properties: + powerProfileId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + name: + description: > + Name of the power profile as provided in the + VNFD. + type: string + powerConsumptionInfo: + description: > + This type represents information about + estimated power consumption of the resources + associated with the power profile, as provided + in the VNFD. + type: object + required: + - minPowerConsumption + - maxPowerConsumption + - averagePowerConsumption + properties: + minPowerConsumption: + description: > + Minimum power consumption of this power + profile. Unit is KW/h. + type: integer + maxPowerConsumption: + description: > + Maximum power consumption of this power + profile. Unit is KW/h. + type: integer + averagePowerConsumption: + description: > + Average power consumption of this power + profile. Unit is KW/h. + type: integer + scaleStatus: + description: > + Scale status of the VNF, one entry per aspect. + Represents for every scaling aspect how "big" the + VNF has been scaled w.r.t. that aspect. + + This attribute shall be present if the VNF + supports scaling. See clause B.2 for an + explanation of VNF scaling. + + For an aspect that has not been deployed because + the related deployableModule has not been + selected, it indicates the scale level that has + been requested in the instantiation or in a + scaling operation, or, if none has been requested + in any of them, the scale level applicable to the + aspect based on the default instantiation level. + See note 8. + type: array + items: + description: > + This type represents the scale level of a VNF + instance related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being + globally unique. + type: string + maxScaleLevels: + description: > + Maximum allowed scale levels of the VNF, one entry + per aspect. This attribute shall be present if the + VNF supports scaling. + type: array + items: + description: > + This type represents the scale level of a VNF + instance related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being + globally unique. + type: string + selectedDeployableModule: + description: > + References a currently selected deployable module, + as defined in the VNFD, that has already + completed the instantiation of its VNFCs. + type: array + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + resourceCapacityDefinition: + description: > + Shows current values of VDU attributes related to + resource capacity, if different to the default + values from the VNFD, as indicated in the (one or + more) request(s) of all completed VNF LCM + operation(s) that contain this attribute. If an + attribute value has been modified multiple times, + only the last value is shown. The values indicated + in this attribute are applicable to all VNFC + instances based on the VDU to which the + resourceCapacityDefinition is related. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes. + + * NOTE: Resource definitions not related to a + VDU are not considered in this version of the + present document. + type: object + required: + - type + properties: + tag: + description: > + Tag assigned by the issuer of a VNF LCM + operation request that contains this data + type with values to be applied to a VDU. It + is used for tracking purposes. + + The tag is preserved in the run time record + as long as at least one value of the + capacity related attributes associated with + that tag is still valid, i.e., it has not + been modified by a later VNF LCM operation + request. + + At most one tag can be included when the + data type is used in a VNF LCM operation + request. + + When the data type is used in the + VnfInstance data type it may contain + multiple tags, namely those provided in VNF + LCM requests, if at least one of the values + provided in that request associated to that + tag is still applicable in the VNFCs created + from this VDU, i.e., it has not been + modified by a later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: | + Type of the resource definition referenced. + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + osContainerDescData: + description: > + Indicates values for resource capacity + related attributes in an OsContainerDesc. + It shall be present when the attribute + 'type' indicates OSCONTAINER and absent + otherwise. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes of an + OsContainer resource. + + * NOTE: At least one of the attributes + shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for + the container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for + the container expressed in the same + units as specified in the + requested_memory_resources_valid_values + property in VNFD (clause 6.8.12 in ETSI + GS NFV-SOL 001 [14]) for this container + descriptor. See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources + of the type indicated in the key. The + key is a string that identifies an + extended resource indicated in the + extended_resource_requests property in + the VNFD (clause 6.8.12 in ETSI GS + NFV-SOL 001 [14]) for this container + descriptor. The value is an integer that + indicates the required amount for a + particular extended resource. See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container + can maximally use in milli-CPU. See + note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required + for all the hugepages of the size + indicated in the key. The key is a + string and corresponds to one of the + values of the hugepage sizes indicated + in the huge_pages_resources property in + the VNFD (clause 6.8.12 in ETSI GS + NFV-SOL 001 [14]) for this container + descriptor. The value is a number that + indicates the required total size + expressed in the same units as in the + huge_pages_resource property in the VNFD + (clause 6.8.12 in ETSI GS NFV-SOL 001 + [14]) that indicates the valid values + for required total size for the + particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power + state configuration data for the virtual + compute or OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU + cores are requested to be allocated to + logical CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states + of virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on + core utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for + capacity related VDU attributes of the + virtual compute resource of a VM. + + * NOTE: At least one of the attributes shall + be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required + for all the hugepages of the size + indicated in the key. The key is a + string and corresponds to one of the + values of the hugepage sizes indicated + in the huge_pages_requirements property + in the VNFD (clause 6.2.7.2 in ETSI GS + NFV-SOL 001 [14]) for this virtual + compute descriptor. The value is a + numberthat indicates the required total + size expressed in the same units as in + the huge_pages_requirements property in + the VNFD (clause 6.2.7.2 in ETSI GS + NFV-SOL 001 [14]) that indicates the + valid vaues for required total size for + the particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power + state configuration data for the virtual + compute or OS container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU + cores are requested to be allocated to + logical CPU cores according to the + cpuOperationalPowerStates attribute. In + case of "DYNAMIC", the CPU power states + of virtual CPU cores can be allocated to + logical CPU cores whose power states can + be adjusted dynamically depending on + core utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size + related attribute in an VirtualStorageDesc. + It shall be present when the attribute + 'type' indicates STORAGE and absent + otherwise. + type: array + items: + description: > + This type represents selected values for + capacity related VDU attributes of the + virtual storage resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + extCpInfo: + description: > + Information about the external CPs exposed by the + VNF instance. When trunking is enabled, the list + of entries includes both, external CPs + corresponding to parent ports of a trunk, and + external CPs associated to sub-ports of a + trunk.See note 7. + type: array + items: + description: "This type represents information about an external CP of a VNF.\n* NOTE 1:\tThe attributes \"associatedVnfcCpId\", \"associatedVipCpId\", \"associatedVirtualCpId\" and \n \"associatedVnfVirtualLinkId\" are mutually exclusive. Exactly one shall be present.\n* NOTE 2:\tAn external CP instance is not associated to a link port in the cases indicated for the \n “extLinkPorts” attribute in clause 4.4.1.11.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network \n attachment definition resource is needed to fulfil the connectivity requirements of the external \n CP, e.g. to build a link redundant mated pair in SR-IOV cases.\n* NOTE 4: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace.\n" + type: object + required: + - id + - cpdId + - cpConfigId + - cpProtocolInfo + oneOf: + - required: + - associatedVnfcCpId + - required: + - associatedVipCpId + - required: + - associatedVnfVirtualLinkId + properties: + id: + 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 + cpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolInfo: + description: | + Network protocol information for this CP. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + extLinkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + associatedVnfcCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVipCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVirtualCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + associatedVnfVirtualLinkId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceInfo” + structure that provides the specification of + the interface to attach the connection point + to a secondary container cluster network. + See notes 3 and 4. + + It shall be present if the external CP is + associated to a VNFC realized by one or a + set of OS containers and is connected to a + secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this VNF CP + instance uses. Shall be present when using + in delegation-mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + cpSecurityGroupInfo: + description: > + This type provides the list of active + security group rules applied to an external + CP instance. The type identifies which + "SecurityGroupRule" specified in the VNFD + are activated and the values of its + attributes. + type: object + required: + - securityGroupRuleId + - etherType + - protocol + - portRangeMin + - portRangeMax + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + description: + description: > + Human readable description of the + security group rule. + type: string + etherType: + description: > + Indicates the protocol carried over the + Ethernet layer. Permitted values: IPV4, + IPV6. + type: string + enum: + - IPV4 + - IPV6 + protocol: + description: > + Indicates the protocol carried over the + IP layer. Permitted values: any protocol + defined in the IANA protocol registry + (refer to clause 9.10.1.2 ofd ETSI GS + NFV-SOL 001 for further information). + type: string + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. + type: integer + vipCpInfo: + description: > + VIP CPs that are part of the VNF instance. Shall + be present when that particular VIP CP of the VNFC + instance is associated to an external CP of the + VNF instance. May be present otherwise. + type: array + minItems: 1 + items: + description: "This type provides information related to virtual IP (VIP) CP.\nNOTE 1:\tIt is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. NOTE 2: If only the value or the presence of this attribute is changed in the \"VipCpInfo\" structure by an LCM operation occurrence, this does not represent a change that requires including a related \"AffectedVipCp\" structure in the VNF LCM operation occurrence notifications or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\n" + type: object + required: + - cpInstanceId + - cpdId + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There + shall be one cpProtocolInfo for layer 3. + There may be one cpProtocolInfo for layer 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + associatedVnfcCpIds: + description: > + Identifiers of the VnfcCps that share the + virtual IP address allocated to the VIP CP + instance. See note. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + virtualCpInfo: + description: > + Virtual CPs that are part of the VNF instance. + Shall be present when a particular Virtual CP is + associated to an external CP of the VNF instance. + May be present otherwise. + type: array + items: + description: > + This type provides information related to a + virtual CP instance of a VNF. + + NOTE 1: A consumer of the VNF LCM interface can + learn the actual VNFC instances implementing the + service + accessible via the virtual CP instance by querying the "vnfcResourceInfo" from the "InstantiatedVnfInfo" + and filtering by corresponding "vduIds" values. + NOTE 2: The information can be omitted because + it is already available as part of the external + CP information in the + VnfExtCpInfo structure. + type: object + required: + - cpInstanceId + - cpdId + - resourceHandle + - vduIds + properties: + cpInstanceId: + 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 + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + cpProtocolInfo: + description: > + Protocol information for this CP. There + shall be one cpProtocolInfo for each layer + protocol supported. This attribute may be + omitted if the virtual CP is exposed as an + external CP. See note 2. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vduIds: + description: > + Reference to the VDU(s) which implement the + service accessible via the virtual CP + instance. See note 1. + type: array + minItems: 1 + items: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + additionalServiceInfo: + description: > + Additional service identification + information of the virtual CP instance. + type: array + items: + description: > + This type provides additional service + information of the virtual CP instance + used to expose properties of the virtual + CP to NFV-MANO. + + NOTE: This attribute shall only be present + if additional information is needed to + identify the service + termination within the VNF, such as for example a URL path information in an HTTP request required + to allow a single virtual CP IP address to be used for several HTTP based services that use the + same port number. + type: object + required: + - portInfo + properties: + portInfo: + description: > + Service port numbers exposed by the + virtual CP instance. + minItems: 1 + type: array + items: + description: > + This type describes the service + identifying port properties exposed by + the virtual CP instance. + type: object + required: + - name + - port + - portConfigurable + properties: + name: + description: > + The name of the port exposed by the + virtual CP instance. + type: string + protocol: + description: > + The L4 protocol for this port exposed by + the virtual CP instance. + + Permitted values: - TCP - UDP - SCTP + type: string + enum: + - TCP + - UDP + - SCTP + port: + description: > + The L4 port number exposed by the + virtual CP instance. + type: integer + portConfigurable: + description: > + The Boolean is a data type having two + values (true and false). + type: boolean + serviceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + extVirtualLinkInfo: + description: > + Information about the external VLs the VNF + instance is connected to. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the current + CP configuration information for the + connection of external CPs to the external + virtual link. See note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be + configured on the CP instances created + from the respective CPD. + + The key of the map which identifies the + individual VnfExtCpConfig entries is of + type "IdentifierInVnf" and is managed by + the NFVO. + + The entries shall be applied by the VNFM + according to the rules of JSON Merge + Patch (see IETF RFC 7396). See notes 2, + 3, 4, 5, 6. In case of deleting an + external CP, the list of instances to be + deleted. + type: object + additionalProperties: + description: > + This type represents an externally + provided link port, or a network + attachment definition resource of + secondary container cluster network, or + network address information per instance + of an external connection point. In the + case of VM-based deployment of the VNFC + exposing the external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based + deployment of the VNFC exposing the + external CP, the VNFM shall use the + network attachment definition resource + of secondary container cluster network + when connecting the CP to the external + VL. + + * NOTE 1: The following conditions apply + to the attributes "linkPortId" and + "cpProtocolData" for an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply + to the attributes “netAttDefResourceId” + and “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is + only applicable for specific cases where + more than one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but + not both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of + being globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create + a dedicated link port for the external + CP. If set to True, the VNFM shall + create a link port. If set to False, the + VNFM shall not create a link port. This + attribute is only applicable for + external CP instances without a floating + IP address that expose a VIP CP instance + for which a dedicated IP address is + allocated. It shall be present in that + case and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceData” structure that + provides the specification of the + interface to attach the external CP to a + secondary container cluster network. It + is only applicable if the external CP is + connected or to be connected to a + secondary container cluster network. It + shall not be present if the external CP + is related to a virtual network not + categorized as secondary container + cluster network. See notes 2, 3 and 4. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects + the CP to a VL and the domain names for + the external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security + groups. The parameters identify which + "SecurityGroupRule" specified in the + VNFD is activated/deactivated and for an + activated security group rule the values + of attributes defined in the VNFD that + can be overriden such as "portRangeMin" + and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extNetAttDefResource: + description: > + Network attachment definition resources that + provide the specification of the interface + to attach connection points to this VL. + type: array + items: + description: > + This type contains information related to + a network attachment definition resource + that provides the specification of the + interface used to connect one or multiple + connection points to a secondary + container cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of + being globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated + to this network attachment definition + resource. Shall be present when the + network attachment definition resource + is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to + this network attachment definition + resource. May be present when the + network attachment definition resource + is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been + configured (statically or dynamically) and + been associated to the CP. + type: array + items: + type: string + extManagedVirtualLinkInfo: + description: > + Information about the externally-managed internal + VLs of the VNF instance. See notes 5 and 6. + type: array + items: + description: > + This type provides information about an + externally-managed virtual link. Note: Both + "vnfLinkPort" and "vnfNetAttDefResource" + attributes can be present in an + "ExtManagedVirtualLinkInfo" to + indicate that a single internal virtual link is providing connectivity for both VM-based and container-based + VNFCs. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + vnfLinkPorts: + description: | + Link ports of this VL. See note. + type: array + items: + description: > + This type represents a link port of an + internal VL of a VNF. + + NOTE 1: Either cpInstanceId with + cpInstanceType set to "EXT_CP" or any + combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 + provides examples for configurations where + both vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is + scoped by the value of "vimConnectionId" + in the "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vnfNetAttDefResource: + description: > + Network attachment definition resources that + provide the specification of the interface + to attach connection points to this VL. See + note. + type: array + items: + description: > + This type contains information related to + a network attachment definition resource + that provides the specification of the + interface used to connect one or multiple + connection points to a secondary + container cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of + being globally unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated + to this network attachment definition + resource. Shall be present when the + network attachment definition resource + is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to + this network attachment definition + resource. May be present when the + network attachment definition resource + is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + extManagedMultisiteVirtualLinkId: + description: > + An identifier with the intention of being + globally unique. + type: string + routingResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + monitoringParameters: + description: | + Active monitoring parameters. + type: array + items: + description: > + This type represents a monitoring parameter that + is tracked by the VNFM, + type: object + required: + - id + - performanceMetric + properties: + id: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + name: + description: > + Human readable name of the monitoring + parameter, as defined in the VNFD. + type: string + performanceMetric: + description: > + Performance metric that is monitored. This + attribute shall contain the related + "Measurement Name" value as defined in + clause 7.2 of ETSI GS NFV-IFA 027. + type: string + localizationLanguage: + description: > + Information about localization language of the VNF + (includes e.g. strings in the VNFD). The + localization languages supported by a VNF can be + declared in the VNFD, and localization language + selection can take place at instantiation time. + The value shall comply with the format defined in + IETF RFC 5646. + type: string + vnfcResourceInfo: + description: > + Information about the virtualised compute and + storage resources used by the VNFCs of the VNF + instance. + type: array + items: + description: "This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance. Depending on the form of virtualisation container of the VNFC:\n - For a VNFC based on VM, a reference to the corresponding VirtualCompute shall be provided, and\n - For a VNFC based on OS container(s), a reference to the Compute MCIO shall be provided. Hence, exposure of\n information by the VNFM to the NFVO is at the MCIO level.\nIn addition, the references to the storage resources depend on the form of the VNFC:\n a) For a VNFC based on VM, storage resource identifiers shall refer to VirtualStorage resources, and\n b) For a VNFC based on OS container(s), storage resource identifiers shall refer to Storage MCIOs.\n\nNOTE 1:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on \n TOSCA specifications.\nNOTE 2:\tA VNFC CP is \"connected to\" an external CP if the VNFC CP is connected to an \n internal VL that exposes an external CP. A VNFC CP is \"exposed as\" an external \n CP if it is connected directly to an external VL.\nNOTE 3:\tThe information can be omitted because it is already available as part of the \n external CP information.\nNOTE 4: If only the value or the presence of this attribute is changed in the \"VnfcResourceInfo\"\n structure by an LCM operation occurrence, this does not represent a change that requires\n including a related \"AffectedVnfc\" structure in the VNF LCM operation occurrence notifications\n or the \"VnfLcmOpOcc\" structure related to this LCM operation occurrence.\nNOTE 5: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment\n definition resource is needed to fulfil the connectivity requirements of the internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. \nNOTE 6: When more than one netAttDefResourceId is indicated, all shall belong to the same namespace. NOTE 7: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual vnfcCpInfo, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n" + type: object + required: + - id + - vduId + - computeResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being + globally unique. + type: string + storageResourceIds: + description: > + References to the VirtualStorage resources + or references to Storage MCIOs. The value + refers to a VirtualStorageResourceInfo item + in the VnfInstance. + type: array + items: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfcCpInfo: + description: > + CPs of the VNFC instance. Shall be present + when that particular CP of the VNFC + instance is exposed as an external CP of + the VNF instance or is connected to an + external CP of the VNF instance. See note + 2. May be present otherwise. See note 7. + type: array + items: + type: object + required: + - id + - cpdId + properties: + id: + 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 + vnfExtCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpProtocolInfo: + description: > + Network protocol information for this + CP. May be omitted if the VNFC CP is + exposed as an external CP. See note 3. + type: array + items: + description: "This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.\nNOTE:\tThis attribute allows to signal the addition of further types of layer and protocol in future versions of the \n present document in a backwards-compatible way. In the current version of the present document, only IP over \n Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + The identifier of layer(s) and + protocol(s) associated to the network + address information. + + Permitted values: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + See note. + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents information about a network address that has been assigned.\nNOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. NOTE 2:\tExactly one of \"addresses\" or \"addressRange\" shall be present. NOTE 3:\tIf the Cp instance represents a subport in a trunk, segmentationId shall be present. \n Otherwise it shall not be present.\nNOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the \n actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the \n transport header of the packets or it may be an identifier used between the application \n and the NFVI networking infrastructure to identify the network sub-interface of the trunk \n port in question. In the latter case the NFVI infrastructure will map this local segmentationId \n to whatever segmentationId is actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationId: + description: > + Identification of the network segment to + which the Cp instance connects to. See + notes 3 and 4. + type: string + ipAddresses: + description: > + Addresses assigned to the CP instance. + Each entry represents IP addresses + assigned by fixed or dynamic IP address + assignment per subnet. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - addresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + addresses: + description: > + Fixed addresses assigned (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + isDynamic: + description: > + Indicates whether this set of addresses + was assigned dynamically (true) or based + on address information provided as input + from the API consumer (false). Shall be + present if "addresses" is present and + shall be absent otherwise. + type: boolean + addressRange: + description: > + An IP address range used, e.g. in case + of egress connections. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents information about a + network address that has been assigned + to a virtual CP. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: - IPV4 - IPV6 + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + addressPoolName: + description: > + Name of an address pool from which an IP + address is assigned to the virtual CP. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have + been configured (statically or + dynamically) and been associated to the + CP. + type: array + items: + type: string + vnfLinkPortId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + parentCpId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + netAttDefResourceId: + description: > + Identifier of the + “NetAttDefResourceInfo” structure that + provides the specification of the + interface to attach the connection point + to a secondary container cluster + network. See notes 5 and 6. It shall be + present if the internal CP is associated + to a VNFC realized by one or a set of OS + containers and is connected to a + secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + certificateContentId: + description: > + Identifier(s) of the + "CertificateContent" structure that + provides the information of the + certificate(s) that this VNFC CP + instance uses. Shall be present when + using in delegation-mode. Otherwise + shall not be present. This attribute + shall be supported when delegation mode + in certificate management is applicable + type: array + items: + description: > + An identifier with the intention of + being globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this VNFC instance + uses. Shall be present when using in + delegation-mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfVirtualLinkResourceInfo: + description: > + Information about the virtualised network + resources used by the VLs of the VNF instance. See + note 6. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used + by an internal VL instance in a VNF instance. + + Note: If only the value or the presence of this + attribute is changed in the + "VnfVirtualLinkResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires including + a related "AffectedVirtualLink" structure in the VNF LCM operation occurrence notifications or the + "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - vnfVirtualLinkDescId + - networkResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + vnfVirtualLinkDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being + globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfLinkPorts: + description: > + Links ports of this VL. Shall be present + when the linkPort is used for external + connectivity by the VNF (refer to + VnfLinkPortInfo). May be present otherwise. + type: array + items: + description: > + This type represents a link port of an + internal VL of a VNF. + + NOTE 1: Either cpInstanceId with + cpInstanceType set to "EXT_CP" or any + combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 + provides examples for configurations where + both vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is + scoped by the value of "vimConnectionId" + in the "resourceHandle" + attribute. + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information + that allows addressing a virtualised + resource that is used by a VNF instance. + Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is + within the scope of the VIM or CISM or + the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container + infrastructure service management is a + Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + cpInstanceType: + description: "Type of the CP instance that is identified by cpInstanceId. Shall be present if \"cpInstanceId\" is present and shall be absent otherwise.\nPermitted values: - VNFC_CP: The link port is connected to a VNFC CP. -\tEXT_CP: The link port is associated to an external CP. See note 1.\n" + type: string + enum: + - VNFC_CP + - EXT_CP + vipCpInstanceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, + but may not be globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + virtualStorageResourceInfo: + description: > + Information on the virtualised storage resource(s) + used as storage for the VNF instance. + type: array + items: + description: > + This type represents the information that allows + addressing a virtualised resource that is used + by a VNF instance. + + Note: If only the value or the presence of this + attribute is changed in the + "VirtualStorageResourceInfo" + structure by an LCM operation occurrence, this does not represent a change that requires + including a related "AffectedVirtualStorage" structure in the VNF LCM operation occurrence + notifications or the "VnfLcmOpOcc" structure related to this LCM operation occurrence. + type: object + required: + - id + - virtualStorageDescId + - storageResource + properties: + id: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being + globally unique. + type: string + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that + allows addressing a virtualised resource + that is used by a VNF instance. Information + about the resource is available from the + VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within + the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance + the resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of + being globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the + VIM or the CISM or the resource + provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource + type specific, and which is available + from the VIM or the CISM or the resource + provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for + compute resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which + the persistent volume claim representing + the storage resource is bound. It may be + present for storage resources in the + scope of the CISM and shall be absent + otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the + MCIO corresponding to the resource is + deployed. This attribute shall be + present if the resource is managed by a + CISM and it shall be absent otherwise. + type: string + zoneId: + description: > + An identifier with the intention of being + globally unique. + type: string + reservationId: + description: > + An identifier with the intention of being + globally unique. + type: string + metadata: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + mcioInfo: + description: > + Information on the MCIO(s) representing VNFC + instance(s) realized by one or a set of OS + containers and created from the same VDU for the + VNF instance. + type: array + items: + description: > + This type provides information about an MCIO + representing the set of VNFC instances realized + by one or a set of OS containers which have + been created based on the same VDU. Within the + CISM, an MCIO controller monitors the actual + state of an MCIO representing the set of VNFC + instances realized by one or a set of OS + containers and compare it to the desired state + For an MCIO related to a VDU that has the + attribute isNumOfInstancesClusterBased set to + FALSE the desired state is specified in the + respective declarative descriptor. For an MCIO + related to a VDU that has the attribute + isNumOfInstancesClusterBased set to TRUE, the + desired state is determined by the number of + CIS-nodes in the cluster that fulfil the VDU + requirements.as specified in the respective + declarative descriptor. It triggers actions + toward the CIS to align the actual to the + desired state. Monitoring the actual state + includes monitoring the number of MCIO instances + available at any specific point in time. In + addition, an MCIO controller maintains + properties and runtime information on the MCIO + instances which have been created based on the + same VDU. The McioInfo data structure provides + the runtime information on the MCIOs obtained + from the MCIO controller. + + NOTE: There are different types of MCIOs. The + set of VNFC instances based on the same VDU is + represented + by one MCIO, e.g. of type Deployment. Each individual VNFC instance is represented by another type + of MCIO, e.g. a POD. + + Runtime information of the set of OS containers + realizing an individual VNFC instance is not + part of the McioInfo data structure; such + runtime information is provided in the + ResourceHandle data structure referenced from + the VnfcResourceInfo. The McioInfo does not + provide runtime information of a constituent + VNFC instance created based on a specific VDU. + + NOTE 1: The type of MCIO as specified in the + declarative descriptor of the MCIO, and that can + be read from + the CISM. EXAMPLE: In case of MCIOs managed by Kubernetes®, the type of MCIO corresponds to the + “kind” property of the declarative descriptor. + NOTE 2: If the attribute additionalInfo is + present, it may contain runtime information on + the actual and + desired state of the MCIO(s). + NOTE 3: When the container infrastructure + service is a Kubernetes® instance, the mcioId is + the combined + values from the kind and name fields of the Kubernetes resource object, separated by a slash. + Example: "Deployment/abcd". + NOTE 4: When the container infrastructure + service is a Kubernetes® instance, the mcioName + is the name + field of the resource object. + type: object + required: + - mcioId + - mcioName + - mcioNamespace + - vduId + - cismId + - mcioType + - desiredInstances + - availableInstances + properties: + mcioId: + description: > + An identifier with the intention of being + globally unique. + type: string + mcioName: + description: > + Human readable name of this MCIO. See note + 4. + type: string + mcioNamespace: + description: | + Namespace of this MCIO. + type: string + vduId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cismId: + description: > + An identifier with the intention of being + globally unique. + type: string + mcioType: + description: > + The type of MCIO. Specific values, their + semantics and associated MCIO types are + defined in clause 5.5.4.9. Additional + values are also permitted. See note 1. + type: string + enum: + - Deployment + - Statefulset + - DaemonSet + desiredInstances: + description: | + Number of desired MCIO instances. + type: integer + availableInstances: + description: | + Number of available MCIO instances. + type: integer + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + certificateContentId: + description: > + Identifier(s) of the "CertificateContent" + structure that provides the information of + the certificate(s) that this MCIO instance + uses. Shall be present when using in + delegation mode. Otherwise shall not be + present. This attribute shall be supported + when delegation mode in certificate + management is applicable. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfPaasServiceInfo: + description: > + Information on the PaaS Services assigned and used + by the VNF instance. + type: array + items: + description: > + This type provides input information about a + PaaS Service that is used by a VNF instance. The + PaasServiceInfo is comprised of various sets of + information. Some information comes from the + VNFD, other information comes from the PaaS + Service assets provided by the NFVO to the VNFM, + and other information is provided at runtime + information about the usage of the PaaS Service. + type: object + required: + - id + - paasServiceId + - paasServiceType + - paasServiceRequestId + - paasServiceHandle + properties: + id: + description: > + An identifier with the intention of being + globally unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being + globally unique. + type: string + paasServiceType: + description: >- + The type of PaaS Service. The value of this + attribute is expected to be matched against + values of the registered PaaS Services in + the PSR. + type: string + paasServiceVersion: + description: | + A version. + type: string + paasServiceRequestId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + paasServiceHandle: + description: > + This type provides information enabling the + access and use of the PaaS Service by the + VNF instance. The type and format of the + handle depends on the form that the PaaS + Service is formed. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of + being globally unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the + list is not significant. In JSON, a set + of keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF + RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate + that the values associated with + different keys can be of different type. + type: object + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + indicators: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + instantiate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + terminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + scaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + heal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + operate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + createSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + revertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + changeCurrentVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperationLinks: + description: > + Links to the most recent LCM operation occurrences + related to this resource. See note 9. + type: object + properties: + recentVnfLcmOperation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmInstantiation: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScale: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmScaleToLevel: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeFlavour: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmTerminate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmHeal: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmOperate: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeExtConn: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmModifyInfo: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmCreateSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmRevertToSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmChangeVnfPkg: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + recentVnfLcmSelectDplMods: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfcSnapshots: + description: > + Information about VNFC snapshots constituting this VNF + snapshot. + type: array + items: + description: "This type represents a VNFC snapshot.\nNOTE 1:\tThe identifier of the compute snapshot resource is assigned during creation of a VNFC snapshot \n being returned from the VIM as output data in the response message of the individual resource \n operations. This attribute shall only be present for a VNFC snapshot that has been newly created \n by the VNFM as a result of the \"Create VNF snapshot task\".\nNOTE 2:\tThe identifier of the storage snapshot resource is assigned during creation of a VNFC snapshot being \n returned from the VIM as output data in the response message of the individual resource operations. \n This attribute shall only be present for a VNFC snapshot with an associated storage resource and that \n has been newly created by the VNFM as a result of the \"Create VNF snapshot task\".\n" + type: object + required: + - id + - vnfcInstanceId + - triggeredAt + - vnfcResourceId + properties: + id: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + vnfcInstanceId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + creationStartedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + creationFinishedAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + vnfcResourceInfoId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + computeSnapshotResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + storageSnapshotResources: + description: > + Mapping of the storage resources associated to the + VNFC with the storage snapshot resources. + type: array + items: + type: object + required: + - storageResourceId + properties: + storageResourceId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but may + not be globally unique. + type: string + storageSnapshotResource: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + userDefinedData: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + vnfStateSnapshotInfo: + description: > + This type represents information about VNF-specific state + snapshot data. + type: object + required: + - checksum + - isEncrypted + properties: + checksum: + description: | + Cheksum description + type: string + isEncrypted: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + userDefinedData: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfStateSnapshot: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualVnfSnapshot.Patch.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the "Individual VNF + snapshot" resource. + Typically, this is due to the fact another + modification is ongoing or that the "Individual VNF + snapshot" resource information is not empty due to + a previously successful modification or currently + being modified due to an underlying VNF snapshot + operation. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute should + convey more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualVnfSnapshot.Patch.412: + description: > + 412 Precondition Failed + + + Shall be returned upon the following error: A precondition given in an + HTTP request header is + + not fulfilled. + + Typically, this is due to an ETag mismatch, indicating that the resource + was modified by + + another entity. + + The response body should contain a ProblemDetails structure, in which + the "detail" + + attribute should convey more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + IndividualVnfSnapshot.Delete.204: + description: > + 204 NO CONTENT + + + Shall be returned when the VNF snapshot resource and the associated VNF + snapshot were + + deleted successfully. + + The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualVnfSnapshot.Delete.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that the VNF snapshot + is in use by some operation such as reverting a VNF + instance to a VNF snapshot or creating a VNF + snapshot package. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualVnfSnapshotState.Get.200: + description: > + 200 OK + + + Shall be returned when the whole content of the VNF state snapshot file + has been read successfully. + + + The message content shall contain a copy of the VNF state snapshot file + and the "Content-Type" HTTP + + header shall be set according to the content type of the VNF state + snapshot file. If the VNF state + + snapshot content is encrypted, the header shall be set to the value + "application/cms" (IETF RFC 7193). + + + If the content type cannot be determined, the header shall be set to the + value "application/octet-stream". + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/*: + schema: + type: string + format: binary + IndividualVnfSnapshotState.Get.206: + description: > + 206 PARTIAL CONTENT + + + If the VNFM supports range requests, this response shall be returned + when a single consecutive byte + + range from the content of the VNF state snapshot file has been read + successfully according to the request. + + + The response body shall contain the requested part of the VNF state + snapshot file. The "Content-Type" HTTP + + header shall be set according to the content type of the VNF state + snapshot file. If the content type cannot + + be determined, the header shall be set to the value + "application/octet-stream". + + + The "Content-Range" HTTP header shall be provided according to IETF RFC + 7233. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Range: + required: true + style: simple + explode: false + schema: + type: string + content: + application/*: + schema: + type: string + format: binary + IndividualVnfSnapshotState.Get.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that the VNF + snapshot creation process is not completed. + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualVnfSnapshotState.Get.416: + description: | + 416 RANGE NOT SATISFIABLE + + Shall be returned upon the following error: The byte + range passed in the "Range" header did not match + any available byte range in the VNF state snapshot + file (e.g. "access after end of file"). + The response body may contain a ProblemDetails + structure + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + diff --git a/v5.3.1/SOL003-VNFLifecycleManagementNotification-API.json b/v5.3.1/SOL003-VNFLifecycleManagementNotification-API.json new file mode 100644 index 00000000..7d97c6d4 --- /dev/null +++ b/v5.3.1/SOL003-VNFLifecycleManagementNotification-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL003 - VNF Lifecycle Management Notification interface","description":"SOL003 - VNF Lifecycle Management Notification interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"2.16.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 003 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/callback/v2"},{"url":"https://127.0.0.1/callback/v2"}],"paths":{"/URI_is_provided_by_the_client_when_creating_the_subscription-VnfLcmOperationOccurrenceNotification":{"parameters":[{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"post":{"description":"The POST method delivers a notification from the API producer to an API consumer. The API consumer shall\nhave previously created an \"Individual subscription\" resource with a matching filter. See clause 5.4.20.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/VnfLcmOperationOccurrenceNotification"},"responses":{"204":{"$ref":""},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"get":{"description":"The GET method allows the API producer to test the notification endpoint that is provided by the API consumer,\ne.g. during subscription. See clause 5.4.20.3.2.\n","responses":{"204":{"$ref":"#/components/responses/VnfLcmOperationOccurrenceNotification.Get.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/URI_is_provided_by_the_client_when_creating_the_subscription-VnfIdentifierCreationNotification":{"parameters":[{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"post":{"description":"The POST method delivers a notification from the API producer to an API consumer. The API consumer shall\nhave previously created an \"Individual subscription\" resource with a matching filter. See clause 5.4.20.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/VnfIdentifierCreationNotification"},"responses":{"204":{"$ref":"#/components/responses/VnfIdentifierCreationNotification.Post.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"get":{"description":"The GET method allows the API producer to test the notification endpoint that is provided by the API consumer,\ne.g. during subscription. See clause 5.4.20.3.2.\n","responses":{"204":{"$ref":"#/components/responses/VnfIdentifierCreationNotification.Get.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/URI_is_provided_by_the_client_when_creating_the_subscription-VnfIdentifierDeletionNotification":{"parameters":[{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"post":{"description":"The POST method delivers a notification from the API producer to an API consumer. The API consumer shall\nhave previously created an \"Individual subscription\" resource with a matching filter. See clause 5.4.20.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/VnfIdentifierDeletionNotification"},"responses":{"204":{"$ref":"#/components/responses/VnfIdentifierDeletionNotification.Post.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"get":{"description":"The GET method allows the API producer to test the notification endpoint that is provided by the API consumer,\ne.g. during subscription. See clause 5.4.20.3.2.\n","responses":{"204":{"$ref":"#/components/responses/VnfIdentifierDeletionNotification.Get.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"requestBodies":{"VnfLcmOperationOccurrenceNotification":{"description":"A notification about lifecycle changes triggered by a VNF LCM operation occurrence..\n","content":{"application/json":{"schema":{"description":"This type represents a VNF lifecycle management operation occurrence notification, which informs the receiver of changes in the VNF lifecycle caused by a VNF LCM operation occurrence.\nThe support of the notification is mandatory. \nThis notification shall be triggered by the VNFM when there is a change in the state of a VNF LCM operation occurrence that changes the VNF lifecycle, which represents an occurrence of one the following LCM operations: - Instantiation of the VNF - Scaling of the VNF instance (including auto-scaling) - Healing of the VNF instance (including auto-healing) - Change of the state of the VNF instance (i.e. Operate VNF) - Change of the deployment flavour of the VNF instance - Change of the external connectivity of the VNF instance - Change of the current VNF package - Selection of deployable modules of the VNF instance - Termination of the VNF instance - Modification of VNF instance information and/or VNF configurable properties through the \"PATCH\" \n method on the \"Individual VNF instance\" resource\n- Creation of a VNF snapshot - Reversion of the VNF instance to a VNF snapshot\nClause 5.6.2 defines the states and state transition of a VNF LCM operation occurrence, and also specifies details of the notifications to be emitted at each state transition. If this is the initial notification about the start of a VNF LCM operation occurrence, it is assumed that the notification is sent by the VNFM before any action (including sending the grant request) is taken as part of the LCM operation. Due to possible race conditions, the \"start\" notification, the grant request and the LCM operation acknowledgment (i.e. the \"202 Accepted\" response) can arrive in any order at the NFVO, and the NFVO shall be able to handle such a situation. If this is a notification about a final or intermediate result state of a VNF LCM operation occurrence, the notification shall be sent after all related actions of the LCM operation that led to this state have been executed. The new state shall be set in the \"Individual VNF LCM operation occurrence\" resource before the notification about the state change is sent. The amount of information provided in the LCM operation occurrence notifications to be issued by the VNFM when a particular subscription matches can be controlled by the API consumer using the \"verbosity\" attribute in the subscription request (see clause 5.5.2.15). The \"verbosity\" setting in a particular individual subscription shall only apply to the LCM operation occurrence notifications triggered by that subscription. However, it shall not affect the amount of information in the \"VnfLcmOpOcc\" structure (see clause 5.5.2.13) which represents the \"Individual LCM operation occurrence\" resource associated with each of the notifications. See clause 5.6.2.2 for further provisions regarding sending this notification, including in cases of handling LCM operation errors.\nNOTE 1:\tShall be present if the \"notificationStatus\" is set to \"RESULT\", the \"verbosity\" attribute is set to \"FULL\" \n and the operation has performed any resource modification. Shall be absent otherwise. This attribute contains \n information about the cumulative changes to virtualised resources that were performed so far by the VNF LCM \n operation occurrence and by any of the error handling procedures for that operation occurrence.\nNOTE 2:\tFor a particular affected VL, there shall be as many \"AffectedVirtualLink\" entries as needed for signalling \n the different types of changes, i.e. one per virtual link and change type. For instance, in the case of signaling \n affected VL instances involving the addition of a particular VL instance with links ports, one \"AffectedVirtualLink\" \n entry signals the addition of the VL by using the \"changeType\" attribute of \"AffectedVirtualLink\" structure equal to \n \"ADDED\", and another \"AffectedVirtualLink\" entry signals the addition of externally visible VNF link ports of the VL \n by using the \"changeType\" equal to \"LINK_PORT_ADDED\".\nNote 3: Not more than one of changedInfo and modificationsTriggeredByVnfPkgChange shall be present.\n","type":"object","required":["id","notificationType","subscriptionId","timeStamp","notificationStatus","operationState","vnfInstanceId","operation","isAutomaticInvocation","vnfLcmOpOccId","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"VnfLcmOperationOccurrenceNotification\" for this notification type.\n","type":"string","enum":["VnfLcmOperationOccurrenceNotification"]},"subscriptionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"notificationStatus":{"description":"Indicates whether this notification reports about the start of a lifecycle operation or the result of a lifecycle operation. Permitted values: * START: Informs about the start of the VNF LCM operation occurrence.\n* RESULT: Informs about the final or intermediate result of the VNF LCM operation occurrence.\n","type":"string","enum":["START","RESULT"]},"operationState":{"description":"STARTING: The LCM operation is starting. PROCESSING: The LCM operation is currently in execution. COMPLETED: The LCM operation has been completed successfully. FAILED_TEMP: The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED: The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK: The LCM operation is currently being rolled back. ROLLED_BACK: The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible.\n","type":"string","enum":["STARTING","PROCESSING","COMPLETED","FAILED_TEMP","FAILED","ROLLING_BACK","ROLLED_BACK"]},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"operation":{"description":"The enumeration LcmOpType defines the permitted values to represent VNF lifecycle operation types in VNF lifecycle management operation occurrence resources and VNF lifecycle management operation occurrence notifications.\nValue | Description ------|------------ INSTANTIATE | Represents the \"Instantiate VNF\" LCM operation. SCALE | Represents the \"Scale VNF\" LCM operation. SCALE_TO_LEVEL | Represents the \"Scale VNF to Level\" LCM operation. CHANGE_FLAVOUR | Represents the \"Change VNF Flavour\" LCM operation. TERMINATE | Represents the \"Terminate VNF\" LCM operation. HEAL | Represents the \"Heal VNF\" LCM operation. OPERATE | Represents the \"Operate VNF\" LCM operation. CHANGE_EXT_CONN | Represents the \"Change external VNF connectivity\" LCM operation. MODIFY_INFO | Represents the \"Modify VNF Information\" LCM operation. CREATE_SNAPSHOT | Represents the \"Create VNF Snapshot\" LCM operation. REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot\" LCM operation. CHANGE_VNFPKG | Represents the \"Change current VNF package\" LCM operation. SELECT_DEPL_MODS | Represents the “Select VNF deployable modules” LCM operation\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","MODIFY_INFO","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","CHANGE_VNFPKG","SELECT_DEPL_MODS"]},"isAutomaticInvocation":{"description":"Set to true if this VNF LCM operation occurrence has been triggered by an automated procedure inside the VNFM (i.e. ScaleVnf / ScaleVnfToLevel triggered by auto-scale, or HealVnf triggered by auto-heal). Set to false otherwise.\n","type":"boolean"},"verbosity":{"description":"The enumeration LcmOpOccNotificationVerbosityType provides values to control the verbosity of LCM operation occurrence notifications. * FULL: This signals a full notification which contains all change details. * SHORT: This signals a short notification which omits large-volume change details to reduce the size of data to be sent via the notification mechanism.\n","type":"string","enum":["FULL","SHORT"]},"vnfLcmOpOccId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"affectedVnfcs":{"description":"Information about VNFC instances that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary VNFCs.\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer \n (i.e. the NFVO) to assist in correlating the resource changes performed during \n the LCM operation with the granted resources in a specific Grant exchange, which \n is identified by the \"grantId\" available in the \"Individual VNF lifecycle management \n operation occurrence\" and the \"id\" in the \"Individual Grant\".\n","type":"object","required":["id","vduId","changeType","computeResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY For a temporary resource, an AffectedVnfc structure exists as long as the temporary resource exists.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY"]},"computeResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"affectedVnfcCpIds":{"description":"Identifiers of CP(s) of the VNFC instance that were affected by the change. Shall be present for those affected CPs of the VNFC instance that are associated to an external CP of the VNF instance. May be present for further affected CPs of the VNFC instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"addedStorageResourceIds":{"description":"References to VirtualStorage resources that have been added. Each value refers to a VirtualStorageResourceInfo item in the VnfInstance that was added to the VNFC. It shall be provided if at least one storage resource was added to the VNFC.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"removedStorageResourceIds":{"description":"References to VirtualStorage resources that have been removed. The value contains the identifier of a VirtualStorageResourceInfo item that has been removed from the VNFC, and might no longer exist in the VnfInstance. It shall be provided if at least one storage resource was removed from the VNFC.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"affectedVirtualLinks":{"description":"Information about VL instances that were affected during the lifecycle operation. See note 1 and note 2.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary VLs, and added or removed VNF link ports.\nNOTE 1:\tWhen signalling the addition (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) of VNF link ports, \n the \"networkResource\" and \"resourceDefinitionId\" attributes refer to the affected virtual link \n instance, not the link port instance. The resource handles of the affected VNF link ports can be \n found by dereferencing the identifiers in the \"vnfLinkPortIds\" attribute.\nNOTE 2:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to \n assist in correlating the resource changes performed during the LCM operation with the granted \n resources in a specific Grant exchange, which is identified by the \"grantId\" available in the \n \"Individual VNF lifecycle management operation occurrence\" and the \"id\" in the \"Individual Grant\".\n","type":"object","required":["id","vnfVirtualLinkDescId","changeType","networkResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change.\nPermitted values: -\tADDED -\tREMOVED -\tMODIFIED -\tTEMPORARY -\tLINK_PORT_ADDED -\tLINK_PORT_REMOVED For a temporary resource, an AffectedVirtualLink structure exists as long as the temporary resource exists. See note 1.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY","LINK_PORT_ADDED","LINK_PORT_REMOVED"]},"networkResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"vnfLinkPortIds":{"description":"Identifiers of the link ports of the affected VL related to the change. Each identifier references a \"VnfLinkPortInfo\" structure.\nShall be set when changeType is equal to \"LINK_PORT_ADDED\" or \"LINK_PORT_REMOVED\", and the related \"VnfLinkPortInfo\" structures are present (case \"added\") or have been present (case \"removed\") in the \"VnfVirtualLinkResourceInfo\" or \"ExtManagedVirtualLinkInfo\" structures that are represented by the \"vnfVirtualLinkResource¬Info\" or \"extManagedVirtualLinkInfo\" attribute in the \"VnfInstance\" structure. See note 1.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"affectedExtLinkPorts":{"description":"Information about external VNF link ports that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added and deleted external link ports (link ports attached to external virtual links).\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to assist in correlating \n the resource changes performed during the LCM operation with the granted resources in a specific Grant exchange, which \n is identified by the \"grantId\" available in the \"Individual VNF lifecycle management operation occurrence\" and the \"id\" \n in the \"Individual Grant\".\n","type":"object","required":["id","changeType","extCpInstanceId","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: -\tADDED - MODIFIED -\tREMOVED\n","type":"string","enum":["ADDED","MODIFIED","REMOVED"]},"extCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"}}}},"affectedVirtualStorages":{"description":"Information about virtualised storage instances that were affected during the lifecycle operation. See note 1.\n","type":"array","items":{"description":"This type provides information about added, deleted, modified and temporary virtual storage resources.\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to \n assist in correlating the resource changes performed during the LCM operation with the granted \n resources in a specific Grant exchange, which is identified by the \"grantId\" available in the \n \"Individual VNF lifecycle management operation occurrence\" and the \"id\" in the \"Individual Grant\".\n","type":"object","required":["id","virtualStorageDescId","changeType","storageResource"],"properties":{"id":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY For a temporary resource, an AffectedVirtualStorage structure exists as long as the temporary resource exists.\n","type":"string","enum":["ADDED","REMOVED","MODIFIED","TEMPORARY"]},"storageResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"changedInfo":{"description":"This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource. The attributes that can be included consist of those requested to be modified explicitly in the \"VnfInfoModificationRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly e.g. when modifying the referenced VNF package.\nNOTE:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) \n was modified implicitly following a request to modify the \"vnfdId\" attribute, by \n copying the value of this attribute from the VNFD in the VNF Package identified by \n the \"vnfdId\" attribute.\n","type":"object","properties":{"vnfInstanceName":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfInstanceDescription":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vimConnectionInfo":{"description":"If present, this attribute signals modifications the \"vimConnectionInfo\" attribute array in \"VnfInstance\".\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfProductName":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"}}},"affectedVipCps":{"description":"Information about virtual IP CP instances that were affected during the execution of the lifecycle management operation, if this notification represents the result of a lifecycle management operation occurrence.\nShall be present if the \"notificationStatus\" is set to \"RESULT\", the \"verbosity\" attribute is set to \"FULL\" and the operation has made any changes to the VIP CP instances of the VNF instance. Shall be absent otherwise. Only information about VIP CP instances that have been added, deleted or modified shall be provided.\n","type":"array","items":{"description":"This type provides information about added, deleted and modified virtual IP CP instances.\n","type":"object","required":["cpInstanceId","cpdId","changeType"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change. Permitted values: -\tADDED -\tREMOVED -\tMODIFIED\n","type":"string","enum":["ADDED","REMOVED","MODIFIED"]}}}},"affectedVirtualCps":{"description":"Information about virtual CP instances that were affected during the execution of the lifecycle management operation, if this notification represents the result of a lifecycle management operation occurrence. Shall be present if the \"notificationStatus\" is set to \"RESULT\", the \"verbosity\" attribute is set to \"FULL\" and the operation has made any changes to the virtual CP instances of the VNF instance. Shall be absent otherwise. Only information about virtual CP instances that have been added, deleted or modified shall be provided.","type":"array","items":{"description":"This type provides information about added, deleted and modified virtual CP instances.\n","type":"object","required":["cpInstanceId","cpdId","changeType"],"properties":{"cpInstanceId":{"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"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change.\nPermitted values:\n - ADDED\n - REMOVED\n - MODIFIED\n","type":"string","enum":["ADDED","REMOVED","MODIFIED"]}}}},"affectedCertificates":{"description":"Information about certificate content that were affected during the execution of the lifecycle management operation, if this notification represents the result of a lifecycle management operation occurrence. Shall be present when using delegation mode, otherwise shall be absent. This attribute shall be supported when delegation mode in certificate management is applicable\n","type":"array","items":{"description":"This type provides input information about added, deleted, and modified certificate contents.\n","type":"object","required":["certificateInfoId","changeType"],"properties":{"certificateInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateBaseProfileId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"securityPolicyId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"cmfInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"certificateContentId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"Signals the type of change.","type":"string","enum":["ADD","REMOVE","MODIFY"]}}}},"changedExtConnectivity":{"description":"Information about changed external connectivity, if this notification represents the result of a lifecycle operation occurrence. Shall be present if the \"notificationStatus\" is set to \"RESULT\", the \"verbosity\" attribute is set to \"FULL\" and the operation has made any changes to the external connectivity of the VNF instance. Shall be absent otherwise. Only information about external VL instances that have been added or modified shall be provided.\n","type":"array","items":{"description":"This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n","type":"object","required":["id","resourceHandle","currentVnfExtCpData"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"extLinkPorts":{"description":"Link ports of this VL.\n","type":"array","items":{"description":"This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"cpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"secondaryCpInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"currentVnfExtCpData":{"description":"Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}},"extNetAttDefResource":{"description":"Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n","type":"array","items":{"description":"This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n","type":"object","required":["netAttDefResourceInfoId","netAttDefResource"],"properties":{"netAttDefResourceInfoId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"associatedExtCpId":{"description":"Identifier of the external CP associated to this network attachment definition resource. Shall be present when the network attachment definition resource is used for external connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"associatedVnfcCpId":{"description":"Identifier of the VNFC CP associated to this network attachment definition resource. May be present when the network attachment definition resource is used for internal connectivity by the VNF.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}}}}},"fullyQualifiedDomainNames":{"description":"Fully qualified domain names that have been configured (statically or dynamically) and been associated to the CP.\n","type":"array","items":{"type":"string"}}}}},"modificationsTriggeredByVnfPkgChange":{"description":"This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource when changing the current VNF package. The attributes that can be included consist of those requested to be modified explicitly in the \"ChangeCurrentVnfPkgRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly during the operation.\nNOTE 1:\tThis attribute represents the delta (semantics as per IETF RFC 7396, JSON Merge Patch) between the value \n of the attribute at the start of the \"Change current VNF package\" operation and the value of the attribute \n at its completion.\nNOTE 2:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) was modified implicitly \n during the related operation and contains a copy of the value of the related attribute from the VNFD in the \n VNF Package identified by the \"vnfdId\" attribute.\n","type":"object","properties":{"vnfConfigurableProperties":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extensions":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"If present, this attribute signals the new value of the \"vnfProvider\" attribute in \"VnfInstance\". See note 2.\n","type":"string"},"vnfProductName":{"description":"If present, this attribute signals the new value of the \"vnfProductName\" attribute in \"VnfInstance\". See note 2.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"vimConnectionInfo":{"description":"If present, this attribute signals the changes to VIM connection info that were passed in the related \"ChangeCurrentVnfPkgRequest\" structure.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"error":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}},"_links":{"description":"This type represents the links to resources that a notification can contain.\n","type":"object","required":["vnfInstance","subscription"],"properties":{"vnfInstance":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"subscription":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfLcmOpOcc":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true},"VnfIdentifierCreationNotification":{"description":"A notification about the creation of a VNF identifier and the related \"Individual VNF instance\" resource.\n","content":{"application/json":{"schema":{"description":"This type represents a VNF identifier creation notification, which informs the receiver of the creation of a new \"Individual VNF instance\" resource and the associated VNF instance identifier. This notification shall be triggered by the VNFM when it has created an \"Individual VNF instance\" resource and the associated VNF instance identifier.\n","type":"object","required":["id","notificationType","subscriptionId","timeStamp","vnfInstanceId","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"VnfIdentifierCreationNotification\" for this notification type.\n","type":"string","enum":["VnfIdentifierCreationNotification"]},"subscriptionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"_links":{"description":"This type represents the links to resources that a notification can contain.\n","type":"object","required":["vnfInstance","subscription"],"properties":{"vnfInstance":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"subscription":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfLcmOpOcc":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true},"VnfIdentifierDeletionNotification":{"description":"A notification about the deletion of a VNF identifier and the related \"Individual VNF instance\" resource.\n","content":{"application/json":{"schema":{"description":"This type represents a VNF identifier deletion notification, which informs the receiver of the deletion of a new \"Individual VNF instance\" resource and the associated VNF instance identifier. This notification shall be triggered by the VNFM when it has deleted an \"Individual VNF instance\" resource and the associated VNF instance identifier.\n","type":"object","required":["id","notificationType","subscriptionId","timeStamp","vnfInstanceId","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"VnfIdentifierDeletionNotification\" for this notification type.\n","type":"string","enum":["VnfIdentifierDeletionNotification"]},"subscriptionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"_links":{"description":"This type represents the links to resources that a notification can contain.\n","type":"object","required":["vnfInstance","subscription"],"properties":{"vnfInstance":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"subscription":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfLcmOpOcc":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true}},"responses":{"VnfLcmOperationOccurrenceNotification.Post.204":{"description":"204 NO CONTENT\n\nShall be returned when the notification has been delivered successfully.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"VnfLcmOperationOccurrenceNotification.Get.204":{"description":"204 NO CONTENT\n\nShall be returned to indicate that the notification endpoint has been tested successfully.\nThe response body shall be empty.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"VnfIdentifierCreationNotification.Post.204":{"description":"204 NO CONTENT\n\nShall be returned when the notification has been delivered successfully.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"VnfIdentifierCreationNotification.Get.204":{"description":"204 NO CONTENT\n\nShall be returned to indicate that the notification endpoint has been tested successfully.\nThe response body shall be empty.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"VnfIdentifierDeletionNotification.Post.204":{"description":"204 NO CONTENT\n\nShall be returned when the notification has been delivered successfully.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"VnfIdentifierDeletionNotification.Get.204":{"description":"204 NO CONTENT\n\nShall be returned to indicate that the notification endpoint has been tested successfully.\nThe response body shall be empty.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}}}}} diff --git a/v5.3.1/SOL003-VNFLifecycleManagementNotification-API.yaml b/v5.3.1/SOL003-VNFLifecycleManagementNotification-API.yaml new file mode 100644 index 00000000..e268bf38 --- /dev/null +++ b/v5.3.1/SOL003-VNFLifecycleManagementNotification-API.yaml @@ -0,0 +1,6786 @@ +openapi: 3.0.2 +info: + title: SOL003 - VNF Lifecycle Management Notification interface + description: | + SOL003 - VNF Lifecycle Management Notification interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '2.16.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 003 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf +servers: + - url: 'http://127.0.0.1/callback/v2' + - url: 'https://127.0.0.1/callback/v2' +paths: + /URI_is_provided_by_the_client_when_creating_the_subscription-VnfLcmOperationOccurrenceNotification: + parameters: + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + post: + description: > + The POST method delivers a notification from the API producer to an API + consumer. The API consumer shall + + have previously created an "Individual subscription" resource with a + matching filter. See clause 5.4.20.3.1. + requestBody: + $ref: '#/components/requestBodies/VnfLcmOperationOccurrenceNotification' + responses: + '204': + $ref: >- + #/components/responses/VnfLcmOperationOccurrenceNotification.Post.204 + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + get: + description: > + The GET method allows the API producer to test the notification endpoint + that is provided by the API consumer, + + e.g. during subscription. See clause 5.4.20.3.2. + responses: + '204': + $ref: '#/components/responses/VnfLcmOperationOccurrenceNotification.Get.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /URI_is_provided_by_the_client_when_creating_the_subscription-VnfIdentifierCreationNotification: + parameters: + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + post: + description: > + The POST method delivers a notification from the API producer to an API + consumer. The API consumer shall + + have previously created an "Individual subscription" resource with a + matching filter. See clause 5.4.20.3.1. + requestBody: + $ref: '#/components/requestBodies/VnfIdentifierCreationNotification' + responses: + '204': + $ref: '#/components/responses/VnfIdentifierCreationNotification.Post.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + get: + description: > + The GET method allows the API producer to test the notification endpoint + that is provided by the API consumer, + + e.g. during subscription. See clause 5.4.20.3.2. + responses: + '204': + $ref: '#/components/responses/VnfIdentifierCreationNotification.Get.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /URI_is_provided_by_the_client_when_creating_the_subscription-VnfIdentifierDeletionNotification: + parameters: + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + post: + description: > + The POST method delivers a notification from the API producer to an API + consumer. The API consumer shall + + have previously created an "Individual subscription" resource with a + matching filter. See clause 5.4.20.3.1. + requestBody: + $ref: '#/components/requestBodies/VnfIdentifierDeletionNotification' + responses: + '204': + $ref: '#/components/responses/VnfIdentifierDeletionNotification.Post.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + get: + description: > + The GET method allows the API producer to test the notification endpoint + that is provided by the API consumer, + + e.g. during subscription. See clause 5.4.20.3.2. + responses: + '204': + $ref: '#/components/responses/VnfIdentifierDeletionNotification.Get.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + requestBodies: + VnfLcmOperationOccurrenceNotification: + description: > + A notification about lifecycle changes triggered by a VNF LCM operation + occurrence.. + content: + application/json: + schema: + description: "This type represents a VNF lifecycle management operation occurrence notification, which informs the receiver of changes in the VNF lifecycle caused by a VNF LCM operation occurrence.\nThe support of the notification is mandatory. \nThis notification shall be triggered by the VNFM when there is a change in the state of a VNF LCM operation occurrence that changes the VNF lifecycle, which represents an occurrence of one the following LCM operations: - Instantiation of the VNF - Scaling of the VNF instance (including auto-scaling) - Healing of the VNF instance (including auto-healing) - Change of the state of the VNF instance (i.e. Operate VNF) - Change of the deployment flavour of the VNF instance - Change of the external connectivity of the VNF instance - Change of the current VNF package - Selection of deployable modules of the VNF instance - Termination of the VNF instance - Modification of VNF instance information and/or VNF configurable properties through the \"PATCH\" \n method on the \"Individual VNF instance\" resource\n- Creation of a VNF snapshot - Reversion of the VNF instance to a VNF snapshot\nClause 5.6.2 defines the states and state transition of a VNF LCM operation occurrence, and also specifies details of the notifications to be emitted at each state transition. If this is the initial notification about the start of a VNF LCM operation occurrence, it is assumed that the notification is sent by the VNFM before any action (including sending the grant request) is taken as part of the LCM operation. Due to possible race conditions, the \"start\" notification, the grant request and the LCM operation acknowledgment (i.e. the \"202 Accepted\" response) can arrive in any order at the NFVO, and the NFVO shall be able to handle such a situation. If this is a notification about a final or intermediate result state of a VNF LCM operation occurrence, the notification shall be sent after all related actions of the LCM operation that led to this state have been executed. The new state shall be set in the \"Individual VNF LCM operation occurrence\" resource before the notification about the state change is sent. The amount of information provided in the LCM operation occurrence notifications to be issued by the VNFM when a particular subscription matches can be controlled by the API consumer using the \"verbosity\" attribute in the subscription request (see clause 5.5.2.15). The \"verbosity\" setting in a particular individual subscription shall only apply to the LCM operation occurrence notifications triggered by that subscription. However, it shall not affect the amount of information in the \"VnfLcmOpOcc\" structure (see clause 5.5.2.13) which represents the \"Individual LCM operation occurrence\" resource associated with each of the notifications. See clause 5.6.2.2 for further provisions regarding sending this notification, including in cases of handling LCM operation errors.\nNOTE 1:\tShall be present if the \"notificationStatus\" is set to \"RESULT\", the \"verbosity\" attribute is set to \"FULL\" \n and the operation has performed any resource modification. Shall be absent otherwise. This attribute contains \n information about the cumulative changes to virtualised resources that were performed so far by the VNF LCM \n operation occurrence and by any of the error handling procedures for that operation occurrence.\nNOTE 2:\tFor a particular affected VL, there shall be as many \"AffectedVirtualLink\" entries as needed for signalling \n the different types of changes, i.e. one per virtual link and change type. For instance, in the case of signaling \n affected VL instances involving the addition of a particular VL instance with links ports, one \"AffectedVirtualLink\" \n entry signals the addition of the VL by using the \"changeType\" attribute of \"AffectedVirtualLink\" structure equal to \n \"ADDED\", and another \"AffectedVirtualLink\" entry signals the addition of externally visible VNF link ports of the VL \n by using the \"changeType\" equal to \"LINK_PORT_ADDED\".\nNote 3: Not more than one of changedInfo and modificationsTriggeredByVnfPkgChange shall be present.\n" + type: object + required: + - id + - notificationType + - subscriptionId + - timeStamp + - notificationStatus + - operationState + - vnfInstanceId + - operation + - isAutomaticInvocation + - vnfLcmOpOccId + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall be + set to "VnfLcmOperationOccurrenceNotification" for this + notification type. + type: string + enum: + - VnfLcmOperationOccurrenceNotification + subscriptionId: + description: | + An identifier with the intention of being globally unique. + type: string + timeStamp: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + notificationStatus: + description: > + Indicates whether this notification reports about the start of + a lifecycle operation or the result of a lifecycle operation. + Permitted values: * START: Informs about the start of the VNF + LCM operation + occurrence. + * RESULT: Informs about the final or intermediate result of + the VNF + LCM operation occurrence. + type: string + enum: + - START + - RESULT + operationState: + description: > + STARTING: The LCM operation is starting. PROCESSING: The LCM + operation is currently in execution. COMPLETED: The LCM + operation has been completed successfully. FAILED_TEMP: The + LCM operation has failed and execution has stopped, but the + execution of the operation is not considered to be closed. + FAILED: The LCM operation has failed and it cannot be retried + or rolled back, as it is determined that such action won't + succeed. ROLLING_BACK: The LCM operation is currently being + rolled back. ROLLED_BACK: The LCM operation has been + successfully rolled back, i.e. The state of the VNF prior to + the original operation invocation has been restored as closely + as possible. + type: string + enum: + - STARTING + - PROCESSING + - COMPLETED + - FAILED_TEMP + - FAILED + - ROLLING_BACK + - ROLLED_BACK + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + operation: + description: > + The enumeration LcmOpType defines the permitted values to + represent VNF lifecycle operation types in VNF lifecycle + management operation occurrence resources and VNF lifecycle + management operation occurrence notifications. + + Value | Description ------|------------ INSTANTIATE | + Represents the "Instantiate VNF" LCM operation. SCALE | + Represents the "Scale VNF" LCM operation. SCALE_TO_LEVEL | + Represents the "Scale VNF to Level" LCM operation. + CHANGE_FLAVOUR | Represents the "Change VNF Flavour" LCM + operation. TERMINATE | Represents the "Terminate VNF" LCM + operation. HEAL | Represents the "Heal VNF" LCM operation. + OPERATE | Represents the "Operate VNF" LCM operation. + CHANGE_EXT_CONN | Represents the "Change external VNF + connectivity" LCM operation. MODIFY_INFO | Represents the + "Modify VNF Information" LCM operation. CREATE_SNAPSHOT | + Represents the "Create VNF Snapshot" LCM operation. + REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot" + LCM operation. CHANGE_VNFPKG | Represents the "Change current + VNF package" LCM operation. SELECT_DEPL_MODS | Represents the + “Select VNF deployable modules” LCM operation + type: string + enum: + - INSTANTIATE + - SCALE + - SCALE_TO_LEVEL + - CHANGE_FLAVOUR + - TERMINATE + - HEAL + - OPERATE + - CHANGE_EXT_CONN + - MODIFY_INFO + - CREATE_SNAPSHOT + - REVERT_TO_SNAPSHOT + - CHANGE_VNFPKG + - SELECT_DEPL_MODS + isAutomaticInvocation: + description: > + Set to true if this VNF LCM operation occurrence has been + triggered by an automated procedure inside the VNFM (i.e. + ScaleVnf / ScaleVnfToLevel triggered by auto-scale, or HealVnf + triggered by auto-heal). Set to false otherwise. + type: boolean + verbosity: + description: > + The enumeration LcmOpOccNotificationVerbosityType provides + values to control the verbosity of LCM operation occurrence + notifications. * FULL: This signals a full notification which + contains all change details. * SHORT: This signals a short + notification which omits large-volume change details to reduce + the size of data to + be sent via the notification mechanism. + type: string + enum: + - FULL + - SHORT + vnfLcmOpOccId: + description: | + An identifier with the intention of being globally unique. + type: string + affectedVnfcs: + description: > + Information about VNFC instances that were affected during the + lifecycle operation. See note 1. + type: array + items: + description: "This type provides information about added, deleted, modified and temporary VNFCs.\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer \n (i.e. the NFVO) to assist in correlating the resource changes performed during \n the LCM operation with the granted resources in a specific Grant exchange, which \n is identified by the \"grantId\" available in the \"Individual VNF lifecycle management \n operation occurrence\" and the \"id\" in the \"Individual Grant\".\n" + type: object + required: + - id + - vduId + - changeType + - computeResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + vduId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: > + Signals the type of change. Permitted values: * ADDED * + REMOVED * MODIFIED * TEMPORARY For a temporary resource, + an AffectedVnfc structure exists as long as the + temporary resource exists. + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + computeResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + resourceDefinitionId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + affectedVnfcCpIds: + description: > + Identifiers of CP(s) of the VNFC instance that were + affected by the change. Shall be present for those + affected CPs of the VNFC instance that are associated to + an external CP of the VNF instance. May be present for + further affected CPs of the VNFC instance. + type: array + items: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + addedStorageResourceIds: + description: > + References to VirtualStorage resources that have been + added. Each value refers to a VirtualStorageResourceInfo + item in the VnfInstance that was added to the VNFC. It + shall be provided if at least one storage resource was + added to the VNFC. + type: array + items: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + removedStorageResourceIds: + description: > + References to VirtualStorage resources that have been + removed. The value contains the identifier of a + VirtualStorageResourceInfo item that has been removed + from the VNFC, and might no longer exist in the + VnfInstance. It shall be provided if at least one + storage resource was removed from the VNFC. + type: array + items: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + affectedVirtualLinks: + description: > + Information about VL instances that were affected during the + lifecycle operation. See note 1 and note 2. + type: array + items: + description: "This type provides information about added, deleted, modified and temporary VLs, and added or removed VNF link ports.\nNOTE 1:\tWhen signalling the addition (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) of VNF link ports, \n the \"networkResource\" and \"resourceDefinitionId\" attributes refer to the affected virtual link \n instance, not the link port instance. The resource handles of the affected VNF link ports can be \n found by dereferencing the identifiers in the \"vnfLinkPortIds\" attribute.\nNOTE 2:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to \n assist in correlating the resource changes performed during the LCM operation with the granted \n resources in a specific Grant exchange, which is identified by the \"grantId\" available in the \n \"Individual VNF lifecycle management operation occurrence\" and the \"id\" in the \"Individual Grant\".\n" + type: object + required: + - id + - vnfVirtualLinkDescId + - changeType + - networkResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + vnfVirtualLinkDescId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: "Signals the type of change.\nPermitted values: -\tADDED -\tREMOVED -\tMODIFIED -\tTEMPORARY -\tLINK_PORT_ADDED -\tLINK_PORT_REMOVED For a temporary resource, an AffectedVirtualLink structure exists as long as the temporary resource exists. See note 1.\n" + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + - LINK_PORT_ADDED + - LINK_PORT_REMOVED + networkResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + vnfLinkPortIds: + description: > + Identifiers of the link ports of the affected VL related + to the change. Each identifier references a + "VnfLinkPortInfo" structure. + + Shall be set when changeType is equal to + "LINK_PORT_ADDED" or "LINK_PORT_REMOVED", and the + related "VnfLinkPortInfo" structures are present (case + "added") or have been present (case "removed") in the + "VnfVirtualLinkResourceInfo" or + "ExtManagedVirtualLinkInfo" structures that are + represented by the "vnfVirtualLinkResource¬Info" or + "extManagedVirtualLinkInfo" attribute in the + "VnfInstance" structure. See note 1. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + resourceDefinitionId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + affectedExtLinkPorts: + description: > + Information about external VNF link ports that were affected + during the lifecycle operation. See note 1. + type: array + items: + description: "This type provides information about added and deleted external link ports (link ports attached to external virtual links).\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to assist in correlating \n the resource changes performed during the LCM operation with the granted resources in a specific Grant exchange, which \n is identified by the \"grantId\" available in the \"Individual VNF lifecycle management operation occurrence\" and the \"id\" \n in the \"Individual Grant\".\n" + type: object + required: + - id + - changeType + - extCpInstanceId + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: "Signals the type of change. Permitted values: -\tADDED - MODIFIED -\tREMOVED\n" + type: string + enum: + - ADDED + - MODIFIED + - REMOVED + extCpInstanceId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + resourceDefinitionId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + affectedVirtualStorages: + description: > + Information about virtualised storage instances that were + affected during the lifecycle operation. See note 1. + type: array + items: + description: "This type provides information about added, deleted, modified and temporary virtual storage resources.\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to \n assist in correlating the resource changes performed during the LCM operation with the granted \n resources in a specific Grant exchange, which is identified by the \"grantId\" available in the \n \"Individual VNF lifecycle management operation occurrence\" and the \"id\" in the \"Individual Grant\".\n" + type: object + required: + - id + - virtualStorageDescId + - changeType + - storageResource + properties: + id: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + virtualStorageDescId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: > + Signals the type of change. Permitted values: * ADDED * + REMOVED * MODIFIED * TEMPORARY For a temporary resource, + an AffectedVirtualStorage structure exists as long as + the temporary resource exists. + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + - TEMPORARY + storageResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + resourceDefinitionId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + changedInfo: + description: "This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource. The attributes that can be included consist of those requested to be modified explicitly in the \"VnfInfoModificationRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly e.g. when modifying the referenced VNF package.\nNOTE:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) \n was modified implicitly following a request to modify the \"vnfdId\" attribute, by \n copying the value of this attribute from the VNFD in the VNF Package identified by \n the \"vnfdId\" attribute.\n" + type: object + properties: + vnfInstanceName: + description: | + A string defined in IETF RFC 8259. + type: string + vnfInstanceDescription: + description: | + A string defined in IETF RFC 8259. + type: string + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + vimConnectionInfo: + description: > + If present, this attribute signals modifications the + "vimConnectionInfo" attribute array in "VnfInstance". + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines + the structure of the "interfaceInfo" and + "accessInfo" attributes, based on the type of the + VIM., CISM, CIR or MCIOP repository. The set of + permitted values is expected to change over time as + new types or versions of VIMs become available. The + ETSI NFV registry of VIM-related information + provides access to information about + VimConnectionInfo definitions for various VIM, CISM, + CIR or MCIOP repository types. The structure of the + registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfProvider: + description: | + A string defined in IETF RFC 8259. + type: string + vnfProductName: + description: | + A string defined in IETF RFC 8259. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + affectedVipCps: + description: > + Information about virtual IP CP instances that were affected + during the execution of the lifecycle management operation, if + this notification represents the result of a lifecycle + management operation occurrence. + + Shall be present if the "notificationStatus" is set to + "RESULT", the "verbosity" attribute is set to "FULL" and the + operation has made any changes to the VIP CP instances of the + VNF instance. Shall be absent otherwise. Only information + about VIP CP instances that have been added, deleted or + modified shall be provided. + type: array + items: + description: > + This type provides information about added, deleted and + modified virtual IP CP instances. + type: object + required: + - cpInstanceId + - cpdId + - changeType + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: "Signals the type of change. Permitted values: -\tADDED -\tREMOVED -\tMODIFIED\n" + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + affectedVirtualCps: + description: >- + Information about virtual CP instances that were affected + during the execution of the lifecycle management operation, if + this notification represents the result of a lifecycle + management operation occurrence. Shall be present if the + "notificationStatus" is set to "RESULT", the "verbosity" + attribute is set to "FULL" and the operation has made any + changes to the virtual CP instances of the VNF instance. Shall + be absent otherwise. Only information about virtual CP + instances that have been added, deleted or modified shall be + provided. + type: array + items: + description: > + This type provides information about added, deleted and + modified virtual CP instances. + type: object + required: + - cpInstanceId + - cpdId + - changeType + properties: + cpInstanceId: + 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 + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: | + Signals the type of change. + Permitted values: + - ADDED + - REMOVED + - MODIFIED + type: string + enum: + - ADDED + - REMOVED + - MODIFIED + affectedCertificates: + description: > + Information about certificate content that were affected + during the execution of the lifecycle management operation, + if this notification represents the result of a lifecycle + management operation occurrence. Shall be present when using + delegation mode, otherwise shall be absent. This attribute + shall be supported when delegation mode in certificate + management is applicable + type: array + items: + description: > + This type provides input information about added, deleted, + and modified certificate contents. + type: object + required: + - certificateInfoId + - changeType + properties: + certificateInfoId: + description: > + An identifier with the intention of being globally + unique. + type: string + certificateBaseProfileId: + description: > + An identifier with the intention of being globally + unique. + type: string + securityPolicyId: + description: > + An identifier with the intention of being globally + unique. + type: string + cmfInfoId: + description: > + An identifier with the intention of being globally + unique. + type: string + certificateContentId: + description: > + An identifier with the intention of being globally + unique. + type: string + changeType: + description: Signals the type of change. + type: string + enum: + - ADD + - REMOVE + - MODIFY + changedExtConnectivity: + description: > + Information about changed external connectivity, if this + notification represents the result of a lifecycle operation + occurrence. Shall be present if the "notificationStatus" is + set to "RESULT", the "verbosity" attribute is set to "FULL" + and the operation has made any changes to the external + connectivity of the VNF instance. Shall be absent otherwise. + Only information about external VL instances that have been + added or modified shall be provided. + type: array + items: + description: "This type represents information about an external VL.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" + type: object + required: + - id + - resourceHandle + - currentVnfExtCpData + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + extLinkPorts: + description: | + Link ports of this VL. + type: array + items: + description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + cpInstanceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + secondaryCpInstanceId: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + currentVnfExtCpData: + description: > + Allows the API consumer to read the current CP + configuration information for the connection of external + CPs to the external virtual link. See note. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. + + The entries shall be applied by the VNFM according + to the rules of JSON Merge Patch (see IETF RFC + 7396). See notes 2, 3, 4, 5, 6. In case of + deleting an external CP, the list of instances to + be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extNetAttDefResource: + description: > + Network attachment definition resources that provide the + specification of the interface to attach connection + points to this VL. + type: array + items: + description: > + This type contains information related to a network + attachment definition resource that provides the + specification of the interface used to connect one or + multiple connection points to a secondary container + cluster network. + type: object + required: + - netAttDefResourceInfoId + - netAttDefResource + properties: + netAttDefResourceInfoId: + description: > + An identifier with the intention of being globally + unique. + type: string + netAttDefResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + associatedExtCpId: + description: > + Identifier of the external CP associated to this + network attachment definition resource. Shall be + present when the network attachment definition + resource is used for external connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + associatedVnfcCpId: + description: > + Identifier of the VNFC CP associated to this + network attachment definition resource. May be + present when the network attachment definition + resource is used for internal connectivity by the + VNF. + type: array + items: + description: > + An identifier that is unique for the respective + type within a VNF instance, but may not be + globally unique. + type: string + fullyQualifiedDomainNames: + description: > + Fully qualified domain names that have been configured + (statically or dynamically) and been associated to the + CP. + type: array + items: + type: string + modificationsTriggeredByVnfPkgChange: + description: "This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource when changing the current VNF package. The attributes that can be included consist of those requested to be modified explicitly in the \"ChangeCurrentVnfPkgRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly during the operation.\nNOTE 1:\tThis attribute represents the delta (semantics as per IETF RFC 7396, JSON Merge Patch) between the value \n of the attribute at the start of the \"Change current VNF package\" operation and the value of the attribute \n at its completion.\nNOTE 2:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) was modified implicitly \n during the related operation and contains a copy of the value of the related attribute from the VNFD in the \n VNF Package identified by the \"vnfdId\" attribute.\n" + type: object + properties: + vnfConfigurableProperties: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + metadata: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + extensions: + description: > + This type represents a list of key-value pairs. The order + of the pairs in the list is not significant. In JSON, a + set of keyvalue pairs is represented as an object. It + shall comply with the provisions defined in clause 4 of + IETF RFC 8259. In the following example, a list of + key-value pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to illustrate that + the values associated with different keys can be of + different type. + type: object + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfProvider: + description: > + If present, this attribute signals the new value of the + "vnfProvider" attribute in "VnfInstance". See note 2. + type: string + vnfProductName: + description: > + If present, this attribute signals the new value of the + "vnfProductName" attribute in "VnfInstance". See note 2. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + vimConnectionInfo: + description: > + If present, this attribute signals the changes to VIM + connection info that were passed in the related + "ChangeCurrentVnfPkgRequest" structure. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines + the structure of the "interfaceInfo" and + "accessInfo" attributes, based on the type of the + VIM., CISM, CIR or MCIOP repository. The set of + permitted values is expected to change over time as + new types or versions of VIMs become available. The + ETSI NFV registry of VIM-related information + provides access to information about + VimConnectionInfo definitions for various VIM, CISM, + CIR or MCIOP repository types. The structure of the + registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + error: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + _links: + description: > + This type represents the links to resources that a + notification can contain. + type: object + required: + - vnfInstance + - subscription + properties: + vnfInstance: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + subscription: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfLcmOpOcc: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + VnfIdentifierCreationNotification: + description: > + A notification about the creation of a VNF identifier and the related + "Individual VNF instance" resource. + content: + application/json: + schema: + description: > + This type represents a VNF identifier creation notification, which + informs the receiver of the creation of a new "Individual VNF + instance" resource and the associated VNF instance identifier. + This notification shall be triggered by the VNFM when it has + created an "Individual VNF instance" resource and the associated + VNF instance identifier. + type: object + required: + - id + - notificationType + - subscriptionId + - timeStamp + - vnfInstanceId + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall be + set to "VnfIdentifierCreationNotification" for this + notification type. + type: string + enum: + - VnfIdentifierCreationNotification + subscriptionId: + description: | + An identifier with the intention of being globally unique. + type: string + timeStamp: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + _links: + description: > + This type represents the links to resources that a + notification can contain. + type: object + required: + - vnfInstance + - subscription + properties: + vnfInstance: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + subscription: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfLcmOpOcc: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + VnfIdentifierDeletionNotification: + description: > + A notification about the deletion of a VNF identifier and the related + "Individual VNF instance" resource. + content: + application/json: + schema: + description: > + This type represents a VNF identifier deletion notification, which + informs the receiver of the deletion of a new "Individual VNF + instance" resource and the associated VNF instance identifier. + This notification shall be triggered by the VNFM when it has + deleted an "Individual VNF instance" resource and the associated + VNF instance identifier. + type: object + required: + - id + - notificationType + - subscriptionId + - timeStamp + - vnfInstanceId + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall be + set to "VnfIdentifierDeletionNotification" for this + notification type. + type: string + enum: + - VnfIdentifierDeletionNotification + subscriptionId: + description: | + An identifier with the intention of being globally unique. + type: string + timeStamp: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + _links: + description: > + This type represents the links to resources that a + notification can contain. + type: object + required: + - vnfInstance + - subscription + properties: + vnfInstance: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + subscription: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfLcmOpOcc: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + responses: + VnfLcmOperationOccurrenceNotification.Post.204: + description: | + 204 NO CONTENT + + Shall be returned when the notification has been delivered successfully. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + VnfLcmOperationOccurrenceNotification.Get.204: + description: > + 204 NO CONTENT + + + Shall be returned to indicate that the notification endpoint has been + tested successfully. + + The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + VnfIdentifierCreationNotification.Post.204: + description: | + 204 NO CONTENT + + Shall be returned when the notification has been delivered successfully. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + VnfIdentifierCreationNotification.Get.204: + description: > + 204 NO CONTENT + + + Shall be returned to indicate that the notification endpoint has been + tested successfully. + + The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + VnfIdentifierDeletionNotification.Post.204: + description: | + 204 NO CONTENT + + Shall be returned when the notification has been delivered successfully. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + VnfIdentifierDeletionNotification.Get.204: + description: > + 204 NO CONTENT + + + Shall be returned to indicate that the notification endpoint has been + tested successfully. + + The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + diff --git a/v5.3.1/SOL003-VNFLifecycleOperationGranting-API.json b/v5.3.1/SOL003-VNFLifecycleOperationGranting-API.json new file mode 100644 index 00000000..542713bb --- /dev/null +++ b/v5.3.1/SOL003-VNFLifecycleOperationGranting-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL003 - VNF Lifecycle Operation Granting interface","description":"SOL003 - VNF Lifecycle Operation Granting interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"1.14.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 003 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/grant/v1"},{"url":"https://127.0.0.1/grant/v1"}],"paths":{"/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/grants":{"post":{"description":"The POST method requests a grant for a particular VNF lifecycle operation. See clause 9.4.2.3.1.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/GrantRequest"},"responses":{"201":{"$ref":"#/components/responses/Grants.Post.201"},"202":{"$ref":"#/components/responses/Grants.Post.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/Grants.Post.403"},"404":{"description":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/grants/{grantId}":{"parameters":[{"$ref":"#/components/parameters/GrantId"}],"get":{"description":"The GET method reads a grant. See clause 9.4.3.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualGrant.Get.200"},"202":{"$ref":"#/components/responses/IndividualGrant.Get.202"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/IndividualGrant.Get.403"},"404":{"description":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"parameters":{"GrantId":{"name":"grantId","in":"path","description":"Identifier of the grant.\nThis identifier can be retrieved from the resource referenced by the\n\"Location\" HTTP header in the response to a POST request granting a\nnew VNF lifecycle operation. It can also be retrieved from the \"id\"\nattribute in the message content of that response.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}}},"requestBodies":{"GrantRequest":{"content":{"application/json":{"schema":{"description":"This type represents a grant request.\nNOTE 1:\tThe VNF LCM operations CreateVnfIdentifier, DeleteVnfIdentifier, QueryVnf and\n ModifyVnfInformation can be executed by the VNFM without requesting granting.\nNOTE 2: If the granting request is for InstantiateVNF, only one of the three parameters (instantiationLevel or\n targetScaleLevelInfo or addResources) shall be present.\nNOTE 3:\tThe NFVO will assume that the VNFM will be responsible to both allocate and release the temporary\n resource during the runtime of the LCM operation. This means, the resource can be allocated and\n consumed after the \"start\" notification for the LCM operation is sent by the VNFM, and the resource\n will be released before the \"result\" notification of the VNF LCM operation is sent by the VNFM. In the \n case of PaaS Service requests, the handling of the allocation and release of the PaaS Service is a \n responsibility of the NFVO (supported by corresponding PaaS Service management functions) \n based on the information about the progress and completion of the VNF LCM operation.\nNOTE 4:\tFor the affinity/anti-affinity rules defined in the VNFD and the placement constraints in the\n GrantVnfLifecycleOperation as defined in this clause, the following applies: Assuming unlimited\n capacity, the combination of all the aforementioned rules shall be satisfiable by at least one possible\n placement of the new resources, with the exception that some of the rules with fallbackBestEffort\n may be unsatisfiable due to the actual placement of existing resources. In this case, rules with\n fallbackBestEffort are allowed to be violated only in relation to the placement of existing resources.\nNOTE 5:\tPassing constraints allows the VNFM or the lifecycle management scripts to influence resource\n placement decisions by the NFVO to ensure VNF properties such as performance or fault tolerance.\nNOTE 6:\tIf fallbackBestEffort is present and set to \"true\" in one or more placement constraints and the NFVO\n cannot find a resource placement that satisfies all of these due to limited capacity, the NFVO shall\n process each such affinity/antiAffinity constraint in a best effort manner, in which case, if specified\n resources cannot be allocated based on the specified placement constraint, the NFVO shal look for\n an alternate best effort placement for the specified resources to be granted. In the best effort antiaffinity case, the resources are expected to be spread optimally over all available instances of scope\n (e.g. zones), and in the best effort affinity case, they are expected to be distributed optimally over as\n few instances of scope as possible. Being able to satisfy a \"best-effort\" constraint in a best effort\n manner only, as defined above, shall not lead to rejecting the grant.\nNOTE 7: The target size for VNF instantiation may be specified in either instantiationLevelId or\n targetScaleLevelInfo, but not both.\nNOTE 8: If targetScaleLevelInfo is specified, information provided in targetScaleLevelInfo shall be used for\n scalable constituents of the VNF (e.g. VDUs/VLs) in the granting process. For scaling aspects not\n specified in targetScaleLevelInfo or for the VNF constituents (e.g.,VDUs/VLs) that are not scalable,\n the default instantiation level as declared in the VNFD shall be used in the granting process.\nNOTE 9: For resources related to a VDU that has the attribute isNumOfInstancesClusterBased set to TRUE, \n only one occurrence of the addResources, or tempResources or removeResources, or \n updateResources shall be included per descriptor indicated in the resourceTemplateId of the \n ResourceDefinition, not one per VNFC instance.\nNOTE 10: If the granting request is for InstantiateVNF and if there are deployable modules defined in the \n applicable VNF DF in the VNFD, either the selectedDeployableModules attribute or the \n addResource attribute shall be included but not both. If selectedDeployableModules is included, \n either the instantiationLevel or targetScaleLevelInfo attribute shall be also included.\n","anyOf":[{"required":["instantiationLevelId"]},{"required":["targetScaleLevelInfo"]},{"required":["addResources"]}],"type":"object","required":["vnfInstanceId","vnfLcmOpOccId","vnfdId","operation","isAutomaticInvocation","_links"],"properties":{"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLcmOpOccId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"dstVnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"flavourId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"operation":{"description":"The enumeration GrantedLcmOperationType defines the permitted values to represent VNF lifecycle operation types in grant requests. Value | Description ------|------------ INSTANTIATE | Represents the \"Instantiate VNF\" LCM operation. SCALE | Represents the \"Scale VNF\" LCM operation. SCALE_TO_LEVEL | Represents the \"Scale VNF to Level\" LCM operation. CHANGE_FLAVOUR | Represents the \"Change VNF Flavour\" LCM operation. TERMINATE | Represents the \"Terminate VNF\" LCM operation. HEAL | Represents the \"Heal VNF\" LCM operation. OPERATE | Represents the \"Operate VNF\" LCM operation. CHANGE_EXT_CONN | Represents the \"Change external VNF connectivity\" LCM operation. CHANGE_VNFPKG | Represents the \"Change current VNF package\" LCM operation. CREATE_SNAPSHOT | Represents the \"Create VNF snapshot\" LCM operation. REVERT_TO_SNAPSHOT | Represents the \"Revert to VNF snapshot\" LCM operation. SELECT_DEPL_MODS | Represents the “Select VNF deployable modules” LCM operation.\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","CHANGE_VNFPKG","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","SELECT_DEPL_MODS"]},"isAutomaticInvocation":{"description":"Set to true if this VNF LCM operation occurrence has been triggered by an automated procedure inside the VNFM (i.e. ScaleVnf / ScaleVnfToLevel triggered by auto-scale, or HealVnf triggered by auto-heal). Set to false otherwise.\n","type":"boolean"},"instantiationLevelId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"targetScaleLevelInfo":{"description":"This attribute shall only be used for Instantiate VNF requests. This is applicable if VNF supports target scale level instantiation.\nThis attribute provides an alternative way to define the resources to be added for the VNFs.\nFor each scaling aspect of the current deployment flavour, the attribute specifies the scale level of VNF constituents (e.g., VDU level) to be instantiated. See notes 2, 7, 8 and 10.\n","type":"array","items":{"description":"This type represents the scale level of a VNF instance related to a scaling aspect.\n","type":"object","required":["aspectId","scaleLevel"],"properties":{"aspectId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"scaleToLevel":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"selectedDeployableModule":{"description":"References a selected deployable module. Resources related to VDUs that belong to not selected deployable modules shall not be considered in the granting\nThis attribute shall only be used for the instantiate VNF request. See note 10.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"resourceCapacityDefinition":{"description":"Indicates values for resource capacity related attributes pertaining to a descriptor, as received in the VNF LCM operation request. The values indicated in this attribute are applicable to all VNFC instances based on the VDU to which the resourceCapacityDefinition is related.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes.\n* NOTE: Resource definitions not related to a VDU are not considered in this version of the present document.\n","type":"object","required":["type"],"properties":{"tag":{"description":"Tag assigned by the issuer of a VNF LCM operation request that contains this data type with values to be applied to a VDU. It is used for tracking purposes.\nThe tag is preserved in the run time record as long as at least one value of the capacity related attributes associated with that tag is still valid, i.e., it has not been modified by a later VNF LCM operation request.\nAt most one tag can be included when the data type is used in a VNF LCM operation request.\nWhen the data type is used in the VnfInstance data type it may contain multiple tags, namely those provided in VNF LCM requests, if at least one of the values provided in that request associated to that tag is still applicable in the VNFCs created from this VDU, i.e., it has not been modified by a later request.\n","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"type":{"description":"Type of the resource definition referenced.\n","type":"string","enum":["COMPUTE","STORAGE","OSCONTAINER"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"osContainerDescData":{"description":"Indicates values for resource capacity related attributes in an OsContainerDesc. It shall be present when the attribute 'type' indicates OSCONTAINER and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of an OsContainer resource.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["requestedCpuResources"]},{"required":["requestedMemoryResources"]},{"required":["requestedEphemeralStorageResources"]},{"required":["extendedResourceRequests"]},{"required":["cpuResourceLimit"]},{"required":["memoryResourceLimit"]},{"required":["ephemeralStorageResourceLimit"]},{"required":["hugePageResources"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container in milli-CPU. See note.\n","type":"integer"},"requestedMemoryResources":{"description":"Amount of memory resources requested for the container expressed in the same units as specified in the requested_memory_resources_valid_values property in VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. See note.\n","type":"array","items":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"Map of the amount of extended resources of the type indicated in the key. The key is a string that identifies an extended resource indicated in the extended_resource_requests property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is an integer that indicates the required amount for a particular extended resource. See note.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU. See note.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_resources property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this container descriptor. The value is a number that indicates the required total size expressed in the same units as in the huge_pages_resource property in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) that indicates the valid values for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"virtualComputeDescData":{"description":"This type represents selected values for capacity related VDU attributes of the virtual compute resource of a VM.\n* NOTE: At least one of the attributes shall be present.\n","type":"object","required":["resourceTemplateId"],"oneOf":[{"required":["numVirtualCpu"]},{"required":["virtualMemSize"]},{"required":["sizeOfVirtualDisk"]},{"required":["hugePagesRequirements"]}],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"numVirtualCpu":{"description":"Number of virtual CPUs. See note.\n","type":"integer"},"virtualMemSize":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"sizeOfVirtualDisk":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePagesRequirements":{"description":"Map of the total size values required for all the hugepages of the size indicated in the key. The key is a string and corresponds to one of the values of the hugepage sizes indicated in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for this virtual compute descriptor. The value is a numberthat indicates the required total size expressed in the same units as in the huge_pages_requirements property in the VNFD (clause 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) that indicates the valid vaues for required total size for the particular hugepage size. See note.\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}},"cpuPowerStateRequirements":{"description":"This type provides virtual CPU power state configuration data for the virtual compute or OS container resource.\n* NOTE 1: In case the value of the cpuPowerStateManagementPolicy attribute is \"DYNAMIC\", dynamic adjustment of CPU power states of logical CPU cores\n should adhere to the range of CPU P and C states defined in the\n cpuOperationalPowerStates attribute.\n* NOTE 2: In case the value of the cpuPowerStateManagementPolicy attribute is \"STATIC\", the cpuOperationalPowerStates attribute shall contain only\n one set of CPU P and C states requested for the virtual CPU.\n If the value of the cpuPowerStateManagementPolicy attribute is\n \"DYNAMIC\", multiple CPU P and C states can be defined to indicate the\n range of allowed P/C state values during dynamic power state management.\n","type":"object","required":["cpuPowerStateManagementPolicy"],"properties":{"cpuPowerStateManagementPolicy":{"description":"Indicates the policy for CPU power state management. Permitted values: * STATIC\n * DYNAMIC\nIn case of \"STATIC\", the virtual CPU cores are requested to be allocated to logical CPU cores according to the cpuOperationalPowerStates attribute. In case of \"DYNAMIC\", the CPU power states of virtual CPU cores can be allocated to logical CPU cores whose power states can be adjusted dynamically depending on core utilization (see note 1).\n","type":"string","enum":["STATIC","DYNAMIC"]},"cpuOperationalPowerStates":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}},"virtualStorageDescData":{"description":"Indicates the value for the storage size related attribute in an VirtualStorageDesc. It shall be present when the attribute 'type' indicates STORAGE and absent otherwise.\n","type":"array","items":{"description":"This type represents selected values for capacity related VDU attributes of the virtual storage resource.\n","type":"object","required":["resourceTemplateId","sizeOfStorage"],"properties":{"resourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"sizeOfStorage":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}}}},"addResources":{"description":"List of resource definitions in the VNFD for resources to be added by the LCM operation which is related to this grant request, with one entry per resource. See notes 2, 9 and 10.\n","type":"array","items":{"description":"This type provides information of an existing or proposed resource or PaaS Service used by the VNF.\nNOTE 1:\tThe use cases UC#4 and UC#5 in Annex A.4 of ETSI GS NFV-IFA 007 provide examples\n for such a configuration.\nNOTE 2:\tIn the context of an operation that changes the current VNF package, the following applies: If this\n ResourceDefinition is related to a resource to be created or modified, the \"vnfdId\" attribute shall\n contain the identifier of the destination VNFD. If this ResourceDefinition is related to a resource\n to be deleted, the \"vnfdId\" attribute shall contain the identifier of the source VNFD. If this\n ResourceDefinition is related to a temporary resource, the \"vnfdId\" attribute shall contain the\n identifier of either the source VNFD or the destination VNFD.\nNOTE 3: In case of the type of the ResourceDefinition is \"OSCONTAINER\", either \n resourceTemplateId or osContainerDesc shall be present.\nNOTE 4: In case the osContainerDesc is not present in the VNFD, while MCIOP(s) is present, \n osContainerDesc shall be included in the GrantVnfLifecycleOperationRequest based on \n the processing result of the MCIOP from CISM.\n","type":"object","oneOf":[{"required":["resourceTemplateId"]},{"required":["osContainerDesc"]}],"required":["id","type"],"properties":{"id":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"type":{"description":"Type of the resource definition referenced. Permitted values: * COMPUTE * VL * STORAGE * LINKPORT * OSCONTAINER * VIRTUALCP * PAASSERVICE\n","type":"string","enum":["COMPUTE","VL","STORAGE","LINKPORT","OSCONTAINER","VIRTUALCP","PAASSERVICE"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceTemplateId":{"description":"Reference to the applicable resource template in the VNFD as follows: - if type=\"VL\" : VnfVirtualLinkDesc\n - if type=\"COMPUTE\": VirtualComputeDesc\n - if type=\"LINKPORT\" : VnfExtCpd\n - if type=\"STORAGE\" : VirtualStorageDesc\n - If type=\"OSCONTAINER\": OsContainerDesc\n - If type=\"VIRTUALCP\": VirtualCpd\n - If type=\"PAASSERVICE\": PaasServiceRequest\nCardinality may be greater than \"1\" when type=\"OSCONTAINER\" and multiple references to OsContainerDesc are present in the VDU indicated by the \"vduId\". See note 3.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"osContainerDesc":{"description":"Resource requirements for the OS Containers. See note 3 and 4.\n","type":"array","items":{"description":"This type describes the properties of a set of co-located container compute resources required for realizing a VDU.\n","type":"object","required":["osContainerDescId","name","description"],"properties":{"osContainerDescId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"description":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container (e.g. in milli-CPU-s).\n","type":"integer"},"requestedMemoryResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"An array of key-value pairs of extended resources required by the container.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Specifies HugePages resources requested for the container, which the container can maximally use (e.g. \"hugepages-2Mi: 100Mi\").\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}},"secondaryResourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"resource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"snapshotResDef":{"description":"This type represents resource definition information related to a snapshot resource.\nNOTE 1:\tIf present, the value of the \"vduId\" (for a related VDU) in the \"VnfcResourceInfo\" \n referred by the \"vnfcInfoId\" of the \"VnfcSnapshotInfo\" shall match the value of the \n \"vduId\" in the resource definition that is signalled in the granting request.\nNOTE 2:\tFor snapshot resource definitions extracted from a VNF snapshot package, only the \n \"vnfcSnapshotId\" and \"storageSnapshotId\" (in case of a storage type of resource) \n are applicable. If the snapshot resource definition is generated as part of a VNF \n snapshot created by the VNFM (that is, not extracted from a VNF snapshot package), \n the \"snapshotResource\" is applicable. This is a similar specification as the one \n defined with the \"vduId\", \"resourceTemplateId\" and \"resource\" attributes provided in \n the ResourceDefinition, but in this case applicable to resources that are defined from \n VNF snapshots instead of VNFD.\n","type":"object","required":["vnfSnapshotId"],"properties":{"vnfSnapshotId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcSnapshotId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"storageSnapshotId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"snapshotResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}},"resourceUsageRequirement":{"description":"The type of resource usage requirement. A resource can be shared among VNF instances or dedicated to a single VNF instance. Permitted values: DEDICATED \n SHARED \nDefault value is \"DEDICATED\".\n","type":"string","enum":["DEDICATED","SHARED"]}}}},"tempResources":{"description":"List of resource definitions in the VNFD for resources to be temporarily instantiated during the runtime of the LCM operation which is related to this grant request, with one entry per resource. See notes 3 and 9.\n","type":"array","items":{"description":"This type provides information of an existing or proposed resource or PaaS Service used by the VNF.\nNOTE 1:\tThe use cases UC#4 and UC#5 in Annex A.4 of ETSI GS NFV-IFA 007 provide examples\n for such a configuration.\nNOTE 2:\tIn the context of an operation that changes the current VNF package, the following applies: If this\n ResourceDefinition is related to a resource to be created or modified, the \"vnfdId\" attribute shall\n contain the identifier of the destination VNFD. If this ResourceDefinition is related to a resource\n to be deleted, the \"vnfdId\" attribute shall contain the identifier of the source VNFD. If this\n ResourceDefinition is related to a temporary resource, the \"vnfdId\" attribute shall contain the\n identifier of either the source VNFD or the destination VNFD.\nNOTE 3: In case of the type of the ResourceDefinition is \"OSCONTAINER\", either \n resourceTemplateId or osContainerDesc shall be present.\nNOTE 4: In case the osContainerDesc is not present in the VNFD, while MCIOP(s) is present, \n osContainerDesc shall be included in the GrantVnfLifecycleOperationRequest based on \n the processing result of the MCIOP from CISM.\n","type":"object","oneOf":[{"required":["resourceTemplateId"]},{"required":["osContainerDesc"]}],"required":["id","type"],"properties":{"id":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"type":{"description":"Type of the resource definition referenced. Permitted values: * COMPUTE * VL * STORAGE * LINKPORT * OSCONTAINER * VIRTUALCP * PAASSERVICE\n","type":"string","enum":["COMPUTE","VL","STORAGE","LINKPORT","OSCONTAINER","VIRTUALCP","PAASSERVICE"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceTemplateId":{"description":"Reference to the applicable resource template in the VNFD as follows: - if type=\"VL\" : VnfVirtualLinkDesc\n - if type=\"COMPUTE\": VirtualComputeDesc\n - if type=\"LINKPORT\" : VnfExtCpd\n - if type=\"STORAGE\" : VirtualStorageDesc\n - If type=\"OSCONTAINER\": OsContainerDesc\n - If type=\"VIRTUALCP\": VirtualCpd\n - If type=\"PAASSERVICE\": PaasServiceRequest\nCardinality may be greater than \"1\" when type=\"OSCONTAINER\" and multiple references to OsContainerDesc are present in the VDU indicated by the \"vduId\". See note 3.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"osContainerDesc":{"description":"Resource requirements for the OS Containers. See note 3 and 4.\n","type":"array","items":{"description":"This type describes the properties of a set of co-located container compute resources required for realizing a VDU.\n","type":"object","required":["osContainerDescId","name","description"],"properties":{"osContainerDescId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"description":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container (e.g. in milli-CPU-s).\n","type":"integer"},"requestedMemoryResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"An array of key-value pairs of extended resources required by the container.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Specifies HugePages resources requested for the container, which the container can maximally use (e.g. \"hugepages-2Mi: 100Mi\").\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}},"secondaryResourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"resource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"snapshotResDef":{"description":"This type represents resource definition information related to a snapshot resource.\nNOTE 1:\tIf present, the value of the \"vduId\" (for a related VDU) in the \"VnfcResourceInfo\" \n referred by the \"vnfcInfoId\" of the \"VnfcSnapshotInfo\" shall match the value of the \n \"vduId\" in the resource definition that is signalled in the granting request.\nNOTE 2:\tFor snapshot resource definitions extracted from a VNF snapshot package, only the \n \"vnfcSnapshotId\" and \"storageSnapshotId\" (in case of a storage type of resource) \n are applicable. If the snapshot resource definition is generated as part of a VNF \n snapshot created by the VNFM (that is, not extracted from a VNF snapshot package), \n the \"snapshotResource\" is applicable. This is a similar specification as the one \n defined with the \"vduId\", \"resourceTemplateId\" and \"resource\" attributes provided in \n the ResourceDefinition, but in this case applicable to resources that are defined from \n VNF snapshots instead of VNFD.\n","type":"object","required":["vnfSnapshotId"],"properties":{"vnfSnapshotId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcSnapshotId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"storageSnapshotId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"snapshotResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}},"resourceUsageRequirement":{"description":"The type of resource usage requirement. A resource can be shared among VNF instances or dedicated to a single VNF instance. Permitted values: DEDICATED \n SHARED \nDefault value is \"DEDICATED\".\n","type":"string","enum":["DEDICATED","SHARED"]}}}},"removeResources":{"description":"Provides the definitions of resources to be removed by the LCM operation which is related to this grant request, with one entry per resource. See note 9.\n","type":"array","items":{"description":"This type provides information of an existing or proposed resource or PaaS Service used by the VNF.\nNOTE 1:\tThe use cases UC#4 and UC#5 in Annex A.4 of ETSI GS NFV-IFA 007 provide examples\n for such a configuration.\nNOTE 2:\tIn the context of an operation that changes the current VNF package, the following applies: If this\n ResourceDefinition is related to a resource to be created or modified, the \"vnfdId\" attribute shall\n contain the identifier of the destination VNFD. If this ResourceDefinition is related to a resource\n to be deleted, the \"vnfdId\" attribute shall contain the identifier of the source VNFD. If this\n ResourceDefinition is related to a temporary resource, the \"vnfdId\" attribute shall contain the\n identifier of either the source VNFD or the destination VNFD.\nNOTE 3: In case of the type of the ResourceDefinition is \"OSCONTAINER\", either \n resourceTemplateId or osContainerDesc shall be present.\nNOTE 4: In case the osContainerDesc is not present in the VNFD, while MCIOP(s) is present, \n osContainerDesc shall be included in the GrantVnfLifecycleOperationRequest based on \n the processing result of the MCIOP from CISM.\n","type":"object","oneOf":[{"required":["resourceTemplateId"]},{"required":["osContainerDesc"]}],"required":["id","type"],"properties":{"id":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"type":{"description":"Type of the resource definition referenced. Permitted values: * COMPUTE * VL * STORAGE * LINKPORT * OSCONTAINER * VIRTUALCP * PAASSERVICE\n","type":"string","enum":["COMPUTE","VL","STORAGE","LINKPORT","OSCONTAINER","VIRTUALCP","PAASSERVICE"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceTemplateId":{"description":"Reference to the applicable resource template in the VNFD as follows: - if type=\"VL\" : VnfVirtualLinkDesc\n - if type=\"COMPUTE\": VirtualComputeDesc\n - if type=\"LINKPORT\" : VnfExtCpd\n - if type=\"STORAGE\" : VirtualStorageDesc\n - If type=\"OSCONTAINER\": OsContainerDesc\n - If type=\"VIRTUALCP\": VirtualCpd\n - If type=\"PAASSERVICE\": PaasServiceRequest\nCardinality may be greater than \"1\" when type=\"OSCONTAINER\" and multiple references to OsContainerDesc are present in the VDU indicated by the \"vduId\". See note 3.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"osContainerDesc":{"description":"Resource requirements for the OS Containers. See note 3 and 4.\n","type":"array","items":{"description":"This type describes the properties of a set of co-located container compute resources required for realizing a VDU.\n","type":"object","required":["osContainerDescId","name","description"],"properties":{"osContainerDescId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"description":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container (e.g. in milli-CPU-s).\n","type":"integer"},"requestedMemoryResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"An array of key-value pairs of extended resources required by the container.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Specifies HugePages resources requested for the container, which the container can maximally use (e.g. \"hugepages-2Mi: 100Mi\").\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}},"secondaryResourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"resource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"snapshotResDef":{"description":"This type represents resource definition information related to a snapshot resource.\nNOTE 1:\tIf present, the value of the \"vduId\" (for a related VDU) in the \"VnfcResourceInfo\" \n referred by the \"vnfcInfoId\" of the \"VnfcSnapshotInfo\" shall match the value of the \n \"vduId\" in the resource definition that is signalled in the granting request.\nNOTE 2:\tFor snapshot resource definitions extracted from a VNF snapshot package, only the \n \"vnfcSnapshotId\" and \"storageSnapshotId\" (in case of a storage type of resource) \n are applicable. If the snapshot resource definition is generated as part of a VNF \n snapshot created by the VNFM (that is, not extracted from a VNF snapshot package), \n the \"snapshotResource\" is applicable. This is a similar specification as the one \n defined with the \"vduId\", \"resourceTemplateId\" and \"resource\" attributes provided in \n the ResourceDefinition, but in this case applicable to resources that are defined from \n VNF snapshots instead of VNFD.\n","type":"object","required":["vnfSnapshotId"],"properties":{"vnfSnapshotId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcSnapshotId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"storageSnapshotId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"snapshotResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}},"resourceUsageRequirement":{"description":"The type of resource usage requirement. A resource can be shared among VNF instances or dedicated to a single VNF instance. Permitted values: DEDICATED \n SHARED \nDefault value is \"DEDICATED\".\n","type":"string","enum":["DEDICATED","SHARED"]}}}},"updateResources":{"description":"Provides the definitions of resources to be modified by the LCM operation which is related to this grant request, with one entry per resource. See note 9.\n","type":"array","items":{"description":"This type provides information of an existing or proposed resource or PaaS Service used by the VNF.\nNOTE 1:\tThe use cases UC#4 and UC#5 in Annex A.4 of ETSI GS NFV-IFA 007 provide examples\n for such a configuration.\nNOTE 2:\tIn the context of an operation that changes the current VNF package, the following applies: If this\n ResourceDefinition is related to a resource to be created or modified, the \"vnfdId\" attribute shall\n contain the identifier of the destination VNFD. If this ResourceDefinition is related to a resource\n to be deleted, the \"vnfdId\" attribute shall contain the identifier of the source VNFD. If this\n ResourceDefinition is related to a temporary resource, the \"vnfdId\" attribute shall contain the\n identifier of either the source VNFD or the destination VNFD.\nNOTE 3: In case of the type of the ResourceDefinition is \"OSCONTAINER\", either \n resourceTemplateId or osContainerDesc shall be present.\nNOTE 4: In case the osContainerDesc is not present in the VNFD, while MCIOP(s) is present, \n osContainerDesc shall be included in the GrantVnfLifecycleOperationRequest based on \n the processing result of the MCIOP from CISM.\n","type":"object","oneOf":[{"required":["resourceTemplateId"]},{"required":["osContainerDesc"]}],"required":["id","type"],"properties":{"id":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"type":{"description":"Type of the resource definition referenced. Permitted values: * COMPUTE * VL * STORAGE * LINKPORT * OSCONTAINER * VIRTUALCP * PAASSERVICE\n","type":"string","enum":["COMPUTE","VL","STORAGE","LINKPORT","OSCONTAINER","VIRTUALCP","PAASSERVICE"]},"vduId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceTemplateId":{"description":"Reference to the applicable resource template in the VNFD as follows: - if type=\"VL\" : VnfVirtualLinkDesc\n - if type=\"COMPUTE\": VirtualComputeDesc\n - if type=\"LINKPORT\" : VnfExtCpd\n - if type=\"STORAGE\" : VirtualStorageDesc\n - If type=\"OSCONTAINER\": OsContainerDesc\n - If type=\"VIRTUALCP\": VirtualCpd\n - If type=\"PAASSERVICE\": PaasServiceRequest\nCardinality may be greater than \"1\" when type=\"OSCONTAINER\" and multiple references to OsContainerDesc are present in the VDU indicated by the \"vduId\". See note 3.\n","type":"array","items":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"}},"osContainerDesc":{"description":"Resource requirements for the OS Containers. See note 3 and 4.\n","type":"array","items":{"description":"This type describes the properties of a set of co-located container compute resources required for realizing a VDU.\n","type":"object","required":["osContainerDescId","name","description"],"properties":{"osContainerDescId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"description":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"requestedCpuResources":{"description":"Number of CPU resources requested for the container (e.g. in milli-CPU-s).\n","type":"integer"},"requestedMemoryResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"requestedEphemeralStorageResources":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"extendedResourceRequests":{"description":"An array of key-value pairs of extended resources required by the container.\n","type":"object","additionalProperties":{"type":"integer"}},"cpuResourceLimit":{"description":"Number of CPU resources the container can maximally use in milli-CPU.\n","type":"integer"},"memoryResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"ephemeralStorageResourceLimit":{"description":"A number defined in IETF RFC 8259.\n","type":"number"},"hugePageResources":{"description":"Specifies HugePages resources requested for the container, which the container can maximally use (e.g. \"hugepages-2Mi: 100Mi\").\n","type":"object","additionalProperties":{"description":"A number defined in IETF RFC 8259.\n","type":"number"}}}}},"secondaryResourceTemplateId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"resource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"snapshotResDef":{"description":"This type represents resource definition information related to a snapshot resource.\nNOTE 1:\tIf present, the value of the \"vduId\" (for a related VDU) in the \"VnfcResourceInfo\" \n referred by the \"vnfcInfoId\" of the \"VnfcSnapshotInfo\" shall match the value of the \n \"vduId\" in the resource definition that is signalled in the granting request.\nNOTE 2:\tFor snapshot resource definitions extracted from a VNF snapshot package, only the \n \"vnfcSnapshotId\" and \"storageSnapshotId\" (in case of a storage type of resource) \n are applicable. If the snapshot resource definition is generated as part of a VNF \n snapshot created by the VNFM (that is, not extracted from a VNF snapshot package), \n the \"snapshotResource\" is applicable. This is a similar specification as the one \n defined with the \"vduId\", \"resourceTemplateId\" and \"resource\" attributes provided in \n the ResourceDefinition, but in this case applicable to resources that are defined from \n VNF snapshots instead of VNFD.\n","type":"object","required":["vnfSnapshotId"],"properties":{"vnfSnapshotId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcSnapshotId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"storageSnapshotId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"snapshotResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}},"resourceUsageRequirement":{"description":"The type of resource usage requirement. A resource can be shared among VNF instances or dedicated to a single VNF instance. Permitted values: DEDICATED \n SHARED \nDefault value is \"DEDICATED\".\n","type":"string","enum":["DEDICATED","SHARED"]}}}},"placementConstraints":{"description":"Placement constraints that the VNFM may send to the NFVO in order to influence the resource placement decision. If sent, the NFVO shall take the constraints into consideration when making resource placement decisions and shall reject the grant if they cannot be honoured. See notes 4, 5 and 6.\n","type":"array","items":{"description":"This type provides information regarding a resource placement constraint. A set of such constraints may be sent by the VNFM to the NFVO to influence the resource placement decisions made by the NFVO as part of the granting process. A placement constraint defines a condition to the placement of new resources, considering other new resources as well as existing resources. EXAMPLE: The following rules influence the placement of a set of resources such that they are placed in the same Network Function Virtualisation Infrastructure Point of Presence (NFVI-PoP) but in different resource zones: {type=\"AFFINITY\"; scope=\"NFVI_POP\"; {resource1,resource2}} {type=\"ANTI_AFFINITY\"; scope=\"ZONE\"; {resource1,resource2}}\nAnnex B in ETSI GS NFV-IFA 011 [10] provides additional description and examples about the usage of the affinity/anti-affinity rules.\n\nNOTE: The \"CIS_NODE\" and “CONTAINER_NAMESPACE” scopes shall only be used to express affinity or antiaffinity relationship between containerized workloads.\n","type":"object","required":["affinityOrAntiAffinity","scope","resource"],"properties":{"affinityOrAntiAffinity":{"description":"The type of the constraint. Permitted values: * AFFINITY * ANTI_AFFINITY\n","type":"string","enum":["AFFINITY","ANTI_AFFINITY"]},"scope":{"description":"The scope of the placement constraint indicating the category of the \"place\" where the constraint applies. Permitted values: - NFVI_POP\n - ZONE\n - ZONE_GROUP\n - NFVI_NODE\n - CIS_NODE\n - CONTAINER_NAMESPACE\n- See note.\n","type":"string","enum":["NFVI_POP","ZONE","ZONE_GROUP","NFVI_NODE","CIS_NODE","CONTAINER_NAMESPACE"]},"resource":{"description":"References to resources in the constraint rule.\n","type":"array","minItems":2,"items":{"description":"This type references a resource either by its VIM-level identifier for existing resources, or by the identifier of a \"ResourceDefinition\" structure in the \"GrantRequest\" structure for new resources.\n","type":"object","required":["idType","resourceId"],"properties":{"idType":{"description":"The type of the identifier. Permitted values: * RES_MGMT: Resource-management-level identifier; this identifier is managed by the VIM in the direct mode of VNF-related resource\n management, and is managed by the NFVO in the indirect mode)\n* GRANT: Reference to the identifier of a \"ResourceDefinition\" structure in the \"GrantRequest\" structure.\n","type":"string","enum":["RES_MGMT","GRANT"]},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"fallbackBestEffort":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"}}}},"vimConstraints":{"description":"Used by the VNFM to require that multiple resources are managed through the same VIM connection. If sent, the NFVO shall take the constraints into consideration when making VIM selection decisions, and shall reject the grant if they cannot be honoured. This attribute shall be supported if VNF-related Resource Management in direct mode is applicable. The applicability and further details of this attribute for indirect mode are left for future specification.\n","type":"array","items":{"description":"This type provides information regarding a VIM selection constraint. A set of such constraints may be sent by the VNFM to the NFVO to influence the VIM selection decisions made by the NFVO as part of the granting process.\n","type":"object","required":["resource"],"properties":{"sameResourceGroup":{"description":"If present and set to true, this signals that the constraint applies not only to the same VIM connection, but also to the same infrastructure resource group.\n","type":"boolean"},"resource":{"description":"References to resources in the constraint rule. The NFVO shall ensure that all resources in this list are managed through the same VIM connection. If \"sameResourceGroup\" is set to true, the NFVO shall further ensure that all resources in this list are part of the same infrastructure resource group in that VIM connection.\n","type":"array","minItems":2,"items":{"description":"This type references a resource either by its VIM-level identifier for existing resources, or by the identifier of a \"ResourceDefinition\" structure in the \"GrantRequest\" structure for new resources.\n","type":"object","required":["idType","resourceId"],"properties":{"idType":{"description":"The type of the identifier. Permitted values: * RES_MGMT: Resource-management-level identifier; this identifier is managed by the VIM in the direct mode of VNF-related resource\n management, and is managed by the NFVO in the indirect mode)\n* GRANT: Reference to the identifier of a \"ResourceDefinition\" structure in the \"GrantRequest\" structure.\n","type":"string","enum":["RES_MGMT","GRANT"]},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}}}},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this request.\n","type":"object","required":["vnfLcmOpOcc","vnfInstance"],"properties":{"vnfLcmOpOcc":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true}},"responses":{"Grants.Post.201":{"description":"201 CREATED\n\nShall be returned when the grant has been created successfully (synchronous mode).\nA representation of the created \"Individual grant\" resource shall be returned in the response body.\nThe HTTP response shall include a \"Location\" HTTP header that indicates the URI of the \"Individual grant\"\nresource just created.\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a grant.\nNOTE 1: This interface allows to signal the use of multiple VIMs per VNF. The specification\n for managing the VNF internal VL requirements across multiple VIMs is supported via\n \"externally-managed internal VLs\" and \"multi-site connectivity services\".\nNOTE 2: Void. NOTE 3: The Grant response allows the NFVO to pass to the VNFM VIM assets related to the VNF \n package that is identified in the corresponding Grant request. Because only the operations\n InstantiateVnf, ChangeCurrentVnfPkg and the update of the vnfdId by PATCH can imply changes\n in the set of VIM assets, the NFVO shall not change this set in any other case. To signal the\n set of VIM assets, the following applies:\n a)\tIf the current LCM operation is InstantiateVnf, the NFVO shall send in the Grant response\n the full set of VIM assets related to the VNF package defined by the vnfdId in the related\n Grant request.\n b)\tIf the current LCM operation is ChangeCurrentVnfPkg, the NFVO shall send in the\n Grant response the full set of VIM assets related to the VNF package defined by the destVnfdId\n in the related Grant request.\n c)\tFor any other operation: If the set of VIM assets has changed since the end of the previous\n granted operation because a PATCH operation has changed the vnfdId between the previous granted\n operation and the operation to which the current granting exchange relates, the NFVO shall send\n in the Grant response the full set of VIM assets related to the VNF package defined by the vnfdId\n in the related Grant request. Otherwise, the NFVO shall either send in the Grant response the full\n set of VIM assets related to the VNF package defined by the vnfdId in the related Grant request, or\n shall not send any VIM assets at all.\n During each LCM operation occurrence other than a \"ChangeCurrentVnfPkg\" operation,\n the VIM assets that relate to the VNF package identified by the current value of\n the vnfdId attribute in the \"VnfInstance\" structure shall be used by the\n VNFM for newly created resources and updated resources.\nNOTE 4: The indication of externally-managed internal VLs is needed in case networks have been\n pre-configured for use with certain VNFs, for instance to ensure that these networks have\n certain properties such as security or acceleration features, or to address particular network\n topologies (e.g., multi-site connectivity). The present document assumes that externally-managed\n internal VLs are managed by the NFVO and created towards the VIM and WIM.\nNOTE 5: For any VNF lifecycle management operation request that allows to pass \"extVirtualLinks\" and/or\n \"extManagedVirtualLinks\" parameters, such as InstantiateVnf, ChangeVnfFlavour, ChangeExtVnfConnectivity or\n ChangeCurrentVnfPackage, the NFVO may provide the \"extVirtualLinks\" and/or \"extManagedVirtualLinks\" attributes\n in the Grant to override the values passed in these parameters previously in the associated VNF lifecycle\n management request, if the lifecycle management request has originated from the NFVO itself. The NFVO shall\n not provide the \"extVirtualLinks\" and/or \"extManagedVirtualLinks\" attributes in the Grant in case the LCM\n request did not originate from the NFVO itself or the granted LCM operation request does not allow to pass\n these parameters.\nNOTE 6: The NFVO shall set the value of the attribute by copying the value from the associated \n GrantRequest.\nNOTE 7: In case of granting an InstantiateVnf request that has originated from the NFVO and that \n did not contain the \"extVirtualLinks\" attribute, this attribute shall be set by the NFVO. \n Further in case of granting an InstantiateVnf request that has originated from the NFVO \n and that did not contain the \"extManagedVirtualLinks\" attribute, this attribute shall be \n set by the NFVO if there is the need to provide information about externally-managed virtual \n links.\nNOTE 8: The resulting \"extVirtualLinks\" or \"extManagedVirtualLinks\" information is calculated as follows: \n In a first step, the information passed in the related LCM operation is applied to the baseline\n information known from earlier LCM operation executions. In a second step, the information passed\n in the Grant is applied to the information resulting from the first step.\nNOTE 9: For resources related to ResourceDefinition whose VDU has the attribute \n isNumOfInstancesClusterBased set to TRUE, only one occurrence of the addResources, or \n tempResources or removeResources, or updateResources shall be included.\n","type":"object","required":["id","vnfInstanceId","vnfLcmOpOccId","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLcmOpOccId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimConnectionInfo":{"description":"Provides information regarding VIM and/or CISM connections that are approved to be used by the VNFM to allocate resources and provides parameters of these VIM and/or CISM connections. The VNFM shall update the \"vimConnectionInfo\" attribute of the \"VnfInstance\" structure by adding unknown entries received in this attribute. This attribute is not intended for the modification of VimConnectionInfo entries passed earlier; for that, the VnfInfoModificationRequest structure shall be used. This attribute shall only be supported when - all or part of the granted resources are managed by a VIM and VNF-related\n Resource Management in direct mode is applicable.\n - all or part of the granted resources are managed by a CISM.\nIn direct mode, this parameter shall be absent if the VIM or CISM information was configured to the VNFM in another way, present otherwise. See note 1.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"cirConnectionInfo":{"description":"Provides information regarding a CIR connection that is approved to be used by the VNFM to obtain information about OS container images. It shall be absent in case of rejection or if the CIR information was configured to the VNFM in another way or if the granted resources are not managed by a CISM, present otherwise.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mciopRepositoryInfo":{"description":"Provides information regarding a MCIOP repository. It shall be absent in case of rejection or if the MCIOP repository information was configured to the VNFM in another way or if the granted resources are not managed by a CISM, present otherwise.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"zones":{"description":"Identifies resource zones where the resources are approved to be allocated by the VNFM.\n","type":"array","items":{"description":"This type provides information regarding a resource zone.\n","type":"object","required":["id","zoneId"],"properties":{"id":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"zoneGroups":{"description":"Information about groups of resource zones that are related and that the NFVO has chosen to fulfil a zoneGroup constraint in the GrantVnfLifecycleOperation request. This information confirms that the NFVO has honoured the zoneGroup constraints that were passed as part of \"placementConstraints\" in the GrantRequest.\n","type":"array","items":{"description":"This type provides information regarding a resource zone group. A resource zone group is a group of one or more related resource zones which can be used in resource placement constraints. To fulfil such constraint, the NFVO may decide to place a resource into any zone that belongs to a particular group. NOTE: A resource zone group can be used to support overflow from one resource zone into another, in case a particular deployment supports only non-elastic resource zones.\n","type":"object","required":["zoneId"],"properties":{"zoneId":{"description":"References of identifiers of \"ZoneInfo\" structures, each of which provides information about a resource zone that belongs to this group.\n","type":"array","items":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"}}}}},"addResources":{"description":"List of resources that are approved to be added, with one entry per resource. See note 9. Shall be set when resources are approved to be added and shall contain the same set of resources requested to be added in the related GrantRequest.\n","type":"array","items":{"description":"This type contains information about a Compute, storage or network resource whose addition/update/deletion was granted. It enables also referencing to a PaaS Service request definition which has been granted. NOTE: If a \"sharedResource\" is provided, the \"reservationId\" and \"resourceProviderId\" shall not be set.\n","type":"object","required":["resourceDefinitionId"],"properties":{"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"reservationId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"zoneId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"resourceGroupId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"containerNamespace":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"mcioConstraints":{"description":"The constraint values to be assigned to MCIOs of a VNF with containerized components. The key in the key-value pair indicates the parameter name of the MCIO constraint in the MCIO declarative descriptor and shall be one of the possible enumeration values of the \"mcioConstraintsParams\" attribute as specified in clause 7.1.6.2.2 of ETSI GS NFV-IFA 011 [10]. The value in the keyvalue pair indicates the value to be assigned to the MCIO constraint. This attribute shall be present if the granted resources are managed by a CISM. The attribute shall be absent if the granted resources are not managed by a CISM.\n","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}},"sharedResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"tempResources":{"description":"List of resources that are approved to be temporarily instantiated during the runtime of the lifecycle operation, with one entry per resource. See note 9. Shall be set when resources are approved to be temporarily instantiated and shall contain the same set of resources requested to be temporarily instantiated in the related GrantRequest.\n","type":"array","items":{"description":"This type contains information about a Compute, storage or network resource whose addition/update/deletion was granted. It enables also referencing to a PaaS Service request definition which has been granted. NOTE: If a \"sharedResource\" is provided, the \"reservationId\" and \"resourceProviderId\" shall not be set.\n","type":"object","required":["resourceDefinitionId"],"properties":{"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"reservationId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"zoneId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"resourceGroupId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"containerNamespace":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"mcioConstraints":{"description":"The constraint values to be assigned to MCIOs of a VNF with containerized components. The key in the key-value pair indicates the parameter name of the MCIO constraint in the MCIO declarative descriptor and shall be one of the possible enumeration values of the \"mcioConstraintsParams\" attribute as specified in clause 7.1.6.2.2 of ETSI GS NFV-IFA 011 [10]. The value in the keyvalue pair indicates the value to be assigned to the MCIO constraint. This attribute shall be present if the granted resources are managed by a CISM. The attribute shall be absent if the granted resources are not managed by a CISM.\n","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}},"sharedResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"removeResources":{"description":"List of resources that are approved to be removed, with one entry per resource. See note 9. Shall be set when resources are approved to be removed and shall contain the same set of resources requested to be removed in the related GrantRequest.\n","type":"array","items":{"description":"This type contains information about a Compute, storage or network resource whose addition/update/deletion was granted. It enables also referencing to a PaaS Service request definition which has been granted. NOTE: If a \"sharedResource\" is provided, the \"reservationId\" and \"resourceProviderId\" shall not be set.\n","type":"object","required":["resourceDefinitionId"],"properties":{"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"reservationId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"zoneId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"resourceGroupId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"containerNamespace":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"mcioConstraints":{"description":"The constraint values to be assigned to MCIOs of a VNF with containerized components. The key in the key-value pair indicates the parameter name of the MCIO constraint in the MCIO declarative descriptor and shall be one of the possible enumeration values of the \"mcioConstraintsParams\" attribute as specified in clause 7.1.6.2.2 of ETSI GS NFV-IFA 011 [10]. The value in the keyvalue pair indicates the value to be assigned to the MCIO constraint. This attribute shall be present if the granted resources are managed by a CISM. The attribute shall be absent if the granted resources are not managed by a CISM.\n","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}},"sharedResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"updateResources":{"description":"List of resources that are approved to be modified, with one entry per resource. See note 9. Shall be set when resources are approved to be updated and shall contain the same set of resources requested to be updated in the related GrantRequest.\n","type":"array","items":{"description":"This type contains information about a Compute, storage or network resource whose addition/update/deletion was granted. It enables also referencing to a PaaS Service request definition which has been granted. NOTE: If a \"sharedResource\" is provided, the \"reservationId\" and \"resourceProviderId\" shall not be set.\n","type":"object","required":["resourceDefinitionId"],"properties":{"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"reservationId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"zoneId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"resourceGroupId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"containerNamespace":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"mcioConstraints":{"description":"The constraint values to be assigned to MCIOs of a VNF with containerized components. The key in the key-value pair indicates the parameter name of the MCIO constraint in the MCIO declarative descriptor and shall be one of the possible enumeration values of the \"mcioConstraintsParams\" attribute as specified in clause 7.1.6.2.2 of ETSI GS NFV-IFA 011 [10]. The value in the keyvalue pair indicates the value to be assigned to the MCIO constraint. This attribute shall be present if the granted resources are managed by a CISM. The attribute shall be absent if the granted resources are not managed by a CISM.\n","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}},"sharedResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"vimAssets":{"description":"Information about assets for the VNF that are defined in VNFD and managed by the NFVO in the VIM/NFVI, such as software images and virtualised compute resource flavours. See note 3.\n","type":"object","properties":{"computeResourceFlavours":{"description":"Mappings between virtual compute descriptors defined in the VNFD and compute resource flavours managed in the VIM.\n","type":"array","items":{"description":"If the VIM requires the use of virtual compute resource flavours during compute resource instantiation, it is assumed that such flavours are selected or created by the NFVO based on the information in the virtual compute descriptor defined in the VNFD. This type defines the mapping between a virtual compute descriptor in the VNFD and the corresponding compute resource flavour managed by the NFVO in the VIM.\n","type":"object","required":["vnfdVirtualComputeDescId","vimFlavourId"],"properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfdVirtualComputeDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vimFlavourId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"softwareImages":{"description":"Mappings between software images defined in the VNFD and software images managed in the VIM.\n","type":"array","items":{"description":"This type contains a mapping between a software image definition the VNFD and the corresponding software image managed by the NFVO in the VIM or CIR which is needed during compute resource instantiation.\nNOTE: For an OS container image, the value of this attribute is a string concatenating the name and tag of the image in the CIR separated by a colon ':' with no spaces, e.g. “dbImage:001”.\n","type":"object","required":["vnfdSoftwareImageId","vimSoftwareImageId"],"properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfdSoftwareImageId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vimSoftwareImageId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"snapshotResources":{"description":"Mappings between snapshot resources defined in the VNF snapshot package and resources managed in the VIM.\n","type":"array","items":{"description":"This type contains a mapping between a snapshot resource definition related to a VNF snapshot and the corresponding resource managed by the NFVO in the VIM which is needed during the revert to VNF snapshot operation.\n","type":"object","required":["vnfSnapshotId","vnfcSnapshotId","vimSnapshotResourceId"],"properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfSnapshotId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcSnapshotId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"storageSnapshotId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vimSnapshotResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"storageAssets":{"description":"Mappings between virtual storages defined in the VNFD and virtual storages managed in the NFVI.\n","type":"array","items":{"description":"This type provides a mapping between a VirtualStorageDesc in the VNFD and the corresponding virtual storage managed by the NFVO in the NFVI.\n","type":"object","required":["virtualStorageDescId","storageClassName"],"properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"storageClassName":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}}}}},"paasAssets":{"description":"Information about PaaS Services assigned to the VNF and that are managed in the PSM by the NFVO.\n","type":"array","items":{"type":"object","required":["paasServiceType","paasServiceId","paasServiceRequestId","paasServiceHandle"],"properties":{"paasServiceType":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceVersion":{"description":"A version.\n","type":"string"},"paasServiceRequestId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"PaasServiceHandle":{"description":"This type provides information enabling the access and use of the PaaS Service by the VNF instance. The type and format of the handle depends on the form that the PaaS Service is formed.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"extVirtualLinks":{"description":"Information about external VLs to connect the VNF to. See notes 5, 7 and 8. If this attribute is present according to note 5 or note 7, it need not contain those entries that are unchanged compared to the entries that were passed in the LCM operation which is related to this granting exchange.\n","type":"array","items":{"description":"This type represents an external VL.\n* NOTE 1:\tA link port is not needed for an external CP instance that exposes a CP in the following cases:\n 1) For a VIP CP directly exposed as an external CP:\n 1.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD.\n 1.2) A dedicated IP address is allocated as VIP address, but the NFVO indicates that no port is needed\n (createExtLinkPort in VnfExtCpConfig set to false).\n 2) For a VIP CP exposed as an external CP via a floating IP address:\n 2.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD, and the VNFC CP\n associated to the VIP CP is also exposed via a floating IP address.\n 3) For a VIRTUAL CP exposed as an external CP.\n 4) For a VNFC CP exposed as an external CP in a secondary container cluster external network or a\n secondary container cluster internal network.\n\n* NOTE 2: An example of the network attachment definition resource when the container infrastructure service\n management is a Kubernetes® instance is a network attachment definition (NAD).\n* NOTE 3: Either \"extCps\" or “extCpsDeletion\" shall be present, but not both.\n","type":"object","required":["id","resourceId"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"extCps":{"description":"External CPs of the VNF to be connected to this external VL. Entries in the list of external CP data that are unchanged need not be supplied if the ExtVirtualLinkData structure is part of a request or response that modifies the external connectivity. See note 3.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}},"extLinkPorts":{"description":"Externally provided link ports to be used to connect external connection points to this external VL. If this attribute is not present, the VNFM shall create the link ports on the external VL except in the cases defined below. See note 1.\n","type":"array","items":{"description":"This type represents an externally provided link port to be used to connect an external connection point to an external VL. * NOTE:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"extNetAttDefResourceData":{"description":"Externally provided network attachment definition resource(s) that provide the specification of the interface to attach external CPs to this external VL. See note 2. It is only applicable if the external VL is realized by a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"This type represents a network attachment definition resource that provides the specification of the interface to be used to connect one or multiple connection points to a secondary container cluster network realizing a VL.\n","type":"object","required":["netAttDefResourceId","resourceHandle"],"properties":{"netAttDefResourceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"extCpsDeletion":{"description":"External CPs of the VNF to be disconnected from this external VL and to be deleted. See note 3.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}}}}},"extManagedVirtualLinks":{"description":"Information about internal VLs that are managed by other entities than the VNFM. See notes 4, 5, 7 and 8.\n","type":"array","items":{"description":"This type represents an externally-managed internal VL.\n* NOTE 1: It is only applicable if the externally-managed VL is realized by a secondary container cluster network. It shall not be present otherwise.\n* NOTE 2: A link port is not needed for a VNFC internal connection point connected to a secondary container cluster network.\n* NOTE 3: An example of the network attachment definition resource when the container infrastructure service management is a Kubernetes® instance is a network attachment definition (NAD).\n\n* NOTE 4: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, an instance of intCp need not be included for each VNFC instance as all instances would contain the same \n information. It is sufficient to include one intCp for the related CPD. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version\n* NOTE 5: Both \"vnfLinkPort\" and \"netAttDefResource\" attributes can be provided in a \"ExtManagedVirtualLinkData\" to indicate that a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs\n","type":"object","required":["id","vnfVirtualLinkDescId","resourceId"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"netAttDefResourceData":{"description":"Externally provided network attachment definition resource(s) that provide the specification of the interface to attach VNFC connection points to this externallymanaged VL. See notes 1, 3 and 5.\n","type":"array","items":{"description":"This type represents a network attachment definition resource that provides the specification of the interface to be used to connect one or multiple connection points to a secondary container cluster network realizing a VL.\n","type":"object","required":["netAttDefResourceId","resourceHandle"],"properties":{"netAttDefResourceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"intCp":{"description":"Internal CPs of the VNF to be connected to this externally-managed VL. See note 1 and 4.\n","type":"array","items":{"description":"This type represents input information related to one or more VNF internal CP instances created based on the same CPD.\nNOTE: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the VNF internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall\n belong to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n","type":"object","required":["cpdId","netAttDefResourceId"],"properties":{"cpdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifiers of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the VNF internal CP created from the CPD identified by cpdId to a secondary container cluster network. See note.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfLinkPort":{"description":"Externally provided link ports to be used to connect VNFC connection points to this externally-managed VL on this network resource. If this attribute is not present, the VNFM shall create the link ports on the externally-managed VL. See notes 2 and 5.\n","type":"array","items":{"description":"This type represents an externally provided link port to be used to connect a VNFC connection point to an externally managed VL.\n","type":"object","required":["vnfLinkPortId","resourceHandle"],"properties":{"vnfLinkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"extManagedMultisiteVirtualLinkId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self","vnfLcmOpOcc","vnfInstance"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfLcmOpOcc":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"Grants.Post.202":{"description":"202 ACCEPTED\n\nShall be returned when the request has been accepted for processing\nand it is expected to take some time to create the grant (asynchronous mode).\nThe response body shall be empty.\nThe HTTP response shall include a \"Location\" HTTP header that indicates the URI\nof the \"Individual grant\" resource that will be created once the granting decision has been made.\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"Grants.Post.403":{"description":"403 FORBIDDEN\n\nShall be returned upon the following error: The grant\nhas been rejected.\nA ProblemDetails structure shall be included in the\nresponse to provide more details about the rejection\nin the \"details\" attribute.\n","headers":{"Location":{"description":"The resource URI of the created subscription resource.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualGrant.Get.200":{"description":"200 OK\n\nShall be returned when the grant has been read successfully.\nA representation of the \"Individual grant\" resource shall be returned in the response body.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a grant.\nNOTE 1: This interface allows to signal the use of multiple VIMs per VNF. The specification\n for managing the VNF internal VL requirements across multiple VIMs is supported via\n \"externally-managed internal VLs\" and \"multi-site connectivity services\".\nNOTE 2: Void. NOTE 3: The Grant response allows the NFVO to pass to the VNFM VIM assets related to the VNF \n package that is identified in the corresponding Grant request. Because only the operations\n InstantiateVnf, ChangeCurrentVnfPkg and the update of the vnfdId by PATCH can imply changes\n in the set of VIM assets, the NFVO shall not change this set in any other case. To signal the\n set of VIM assets, the following applies:\n a)\tIf the current LCM operation is InstantiateVnf, the NFVO shall send in the Grant response\n the full set of VIM assets related to the VNF package defined by the vnfdId in the related\n Grant request.\n b)\tIf the current LCM operation is ChangeCurrentVnfPkg, the NFVO shall send in the\n Grant response the full set of VIM assets related to the VNF package defined by the destVnfdId\n in the related Grant request.\n c)\tFor any other operation: If the set of VIM assets has changed since the end of the previous\n granted operation because a PATCH operation has changed the vnfdId between the previous granted\n operation and the operation to which the current granting exchange relates, the NFVO shall send\n in the Grant response the full set of VIM assets related to the VNF package defined by the vnfdId\n in the related Grant request. Otherwise, the NFVO shall either send in the Grant response the full\n set of VIM assets related to the VNF package defined by the vnfdId in the related Grant request, or\n shall not send any VIM assets at all.\n During each LCM operation occurrence other than a \"ChangeCurrentVnfPkg\" operation,\n the VIM assets that relate to the VNF package identified by the current value of\n the vnfdId attribute in the \"VnfInstance\" structure shall be used by the\n VNFM for newly created resources and updated resources.\nNOTE 4: The indication of externally-managed internal VLs is needed in case networks have been\n pre-configured for use with certain VNFs, for instance to ensure that these networks have\n certain properties such as security or acceleration features, or to address particular network\n topologies (e.g., multi-site connectivity). The present document assumes that externally-managed\n internal VLs are managed by the NFVO and created towards the VIM and WIM.\nNOTE 5: For any VNF lifecycle management operation request that allows to pass \"extVirtualLinks\" and/or\n \"extManagedVirtualLinks\" parameters, such as InstantiateVnf, ChangeVnfFlavour, ChangeExtVnfConnectivity or\n ChangeCurrentVnfPackage, the NFVO may provide the \"extVirtualLinks\" and/or \"extManagedVirtualLinks\" attributes\n in the Grant to override the values passed in these parameters previously in the associated VNF lifecycle\n management request, if the lifecycle management request has originated from the NFVO itself. The NFVO shall\n not provide the \"extVirtualLinks\" and/or \"extManagedVirtualLinks\" attributes in the Grant in case the LCM\n request did not originate from the NFVO itself or the granted LCM operation request does not allow to pass\n these parameters.\nNOTE 6: The NFVO shall set the value of the attribute by copying the value from the associated \n GrantRequest.\nNOTE 7: In case of granting an InstantiateVnf request that has originated from the NFVO and that \n did not contain the \"extVirtualLinks\" attribute, this attribute shall be set by the NFVO. \n Further in case of granting an InstantiateVnf request that has originated from the NFVO \n and that did not contain the \"extManagedVirtualLinks\" attribute, this attribute shall be \n set by the NFVO if there is the need to provide information about externally-managed virtual \n links.\nNOTE 8: The resulting \"extVirtualLinks\" or \"extManagedVirtualLinks\" information is calculated as follows: \n In a first step, the information passed in the related LCM operation is applied to the baseline\n information known from earlier LCM operation executions. In a second step, the information passed\n in the Grant is applied to the information resulting from the first step.\nNOTE 9: For resources related to ResourceDefinition whose VDU has the attribute \n isNumOfInstancesClusterBased set to TRUE, only one occurrence of the addResources, or \n tempResources or removeResources, or updateResources shall be included.\n","type":"object","required":["id","vnfInstanceId","vnfLcmOpOccId","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLcmOpOccId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimConnectionInfo":{"description":"Provides information regarding VIM and/or CISM connections that are approved to be used by the VNFM to allocate resources and provides parameters of these VIM and/or CISM connections. The VNFM shall update the \"vimConnectionInfo\" attribute of the \"VnfInstance\" structure by adding unknown entries received in this attribute. This attribute is not intended for the modification of VimConnectionInfo entries passed earlier; for that, the VnfInfoModificationRequest structure shall be used. This attribute shall only be supported when - all or part of the granted resources are managed by a VIM and VNF-related\n Resource Management in direct mode is applicable.\n - all or part of the granted resources are managed by a CISM.\nIn direct mode, this parameter shall be absent if the VIM or CISM information was configured to the VNFM in another way, present otherwise. See note 1.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"cirConnectionInfo":{"description":"Provides information regarding a CIR connection that is approved to be used by the VNFM to obtain information about OS container images. It shall be absent in case of rejection or if the CIR information was configured to the VNFM in another way or if the granted resources are not managed by a CISM, present otherwise.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"mciopRepositoryInfo":{"description":"Provides information regarding a MCIOP repository. It shall be absent in case of rejection or if the MCIOP repository information was configured to the VNFM in another way or if the granted resources are not managed by a CISM, present otherwise.\n","type":"object","additionalProperties":{"description":"This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n","type":"object","required":["vimType"],"properties":{"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimType":{"description":"Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the \"interfaceInfo\" and \"accessInfo\" attributes, based on the type of the VIM., CISM, CIR or MCIOP repository. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM, CISM, CIR or MCIOP repository types. The structure of the registry is defined in annex C.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"zones":{"description":"Identifies resource zones where the resources are approved to be allocated by the VNFM.\n","type":"array","items":{"description":"This type provides information regarding a resource zone.\n","type":"object","required":["id","zoneId"],"properties":{"id":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"zoneId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"zoneGroups":{"description":"Information about groups of resource zones that are related and that the NFVO has chosen to fulfil a zoneGroup constraint in the GrantVnfLifecycleOperation request. This information confirms that the NFVO has honoured the zoneGroup constraints that were passed as part of \"placementConstraints\" in the GrantRequest.\n","type":"array","items":{"description":"This type provides information regarding a resource zone group. A resource zone group is a group of one or more related resource zones which can be used in resource placement constraints. To fulfil such constraint, the NFVO may decide to place a resource into any zone that belongs to a particular group. NOTE: A resource zone group can be used to support overflow from one resource zone into another, in case a particular deployment supports only non-elastic resource zones.\n","type":"object","required":["zoneId"],"properties":{"zoneId":{"description":"References of identifiers of \"ZoneInfo\" structures, each of which provides information about a resource zone that belongs to this group.\n","type":"array","items":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"}}}}},"addResources":{"description":"List of resources that are approved to be added, with one entry per resource. See note 9. Shall be set when resources are approved to be added and shall contain the same set of resources requested to be added in the related GrantRequest.\n","type":"array","items":{"description":"This type contains information about a Compute, storage or network resource whose addition/update/deletion was granted. It enables also referencing to a PaaS Service request definition which has been granted. NOTE: If a \"sharedResource\" is provided, the \"reservationId\" and \"resourceProviderId\" shall not be set.\n","type":"object","required":["resourceDefinitionId"],"properties":{"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"reservationId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"zoneId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"resourceGroupId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"containerNamespace":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"mcioConstraints":{"description":"The constraint values to be assigned to MCIOs of a VNF with containerized components. The key in the key-value pair indicates the parameter name of the MCIO constraint in the MCIO declarative descriptor and shall be one of the possible enumeration values of the \"mcioConstraintsParams\" attribute as specified in clause 7.1.6.2.2 of ETSI GS NFV-IFA 011 [10]. The value in the keyvalue pair indicates the value to be assigned to the MCIO constraint. This attribute shall be present if the granted resources are managed by a CISM. The attribute shall be absent if the granted resources are not managed by a CISM.\n","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}},"sharedResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"tempResources":{"description":"List of resources that are approved to be temporarily instantiated during the runtime of the lifecycle operation, with one entry per resource. See note 9. Shall be set when resources are approved to be temporarily instantiated and shall contain the same set of resources requested to be temporarily instantiated in the related GrantRequest.\n","type":"array","items":{"description":"This type contains information about a Compute, storage or network resource whose addition/update/deletion was granted. It enables also referencing to a PaaS Service request definition which has been granted. NOTE: If a \"sharedResource\" is provided, the \"reservationId\" and \"resourceProviderId\" shall not be set.\n","type":"object","required":["resourceDefinitionId"],"properties":{"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"reservationId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"zoneId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"resourceGroupId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"containerNamespace":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"mcioConstraints":{"description":"The constraint values to be assigned to MCIOs of a VNF with containerized components. The key in the key-value pair indicates the parameter name of the MCIO constraint in the MCIO declarative descriptor and shall be one of the possible enumeration values of the \"mcioConstraintsParams\" attribute as specified in clause 7.1.6.2.2 of ETSI GS NFV-IFA 011 [10]. The value in the keyvalue pair indicates the value to be assigned to the MCIO constraint. This attribute shall be present if the granted resources are managed by a CISM. The attribute shall be absent if the granted resources are not managed by a CISM.\n","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}},"sharedResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"removeResources":{"description":"List of resources that are approved to be removed, with one entry per resource. See note 9. Shall be set when resources are approved to be removed and shall contain the same set of resources requested to be removed in the related GrantRequest.\n","type":"array","items":{"description":"This type contains information about a Compute, storage or network resource whose addition/update/deletion was granted. It enables also referencing to a PaaS Service request definition which has been granted. NOTE: If a \"sharedResource\" is provided, the \"reservationId\" and \"resourceProviderId\" shall not be set.\n","type":"object","required":["resourceDefinitionId"],"properties":{"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"reservationId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"zoneId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"resourceGroupId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"containerNamespace":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"mcioConstraints":{"description":"The constraint values to be assigned to MCIOs of a VNF with containerized components. The key in the key-value pair indicates the parameter name of the MCIO constraint in the MCIO declarative descriptor and shall be one of the possible enumeration values of the \"mcioConstraintsParams\" attribute as specified in clause 7.1.6.2.2 of ETSI GS NFV-IFA 011 [10]. The value in the keyvalue pair indicates the value to be assigned to the MCIO constraint. This attribute shall be present if the granted resources are managed by a CISM. The attribute shall be absent if the granted resources are not managed by a CISM.\n","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}},"sharedResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"updateResources":{"description":"List of resources that are approved to be modified, with one entry per resource. See note 9. Shall be set when resources are approved to be updated and shall contain the same set of resources requested to be updated in the related GrantRequest.\n","type":"array","items":{"description":"This type contains information about a Compute, storage or network resource whose addition/update/deletion was granted. It enables also referencing to a PaaS Service request definition which has been granted. NOTE: If a \"sharedResource\" is provided, the \"reservationId\" and \"resourceProviderId\" shall not be set.\n","type":"object","required":["resourceDefinitionId"],"properties":{"resourceDefinitionId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"reservationId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"zoneId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"resourceGroupId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"containerNamespace":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"mcioConstraints":{"description":"The constraint values to be assigned to MCIOs of a VNF with containerized components. The key in the key-value pair indicates the parameter name of the MCIO constraint in the MCIO declarative descriptor and shall be one of the possible enumeration values of the \"mcioConstraintsParams\" attribute as specified in clause 7.1.6.2.2 of ETSI GS NFV-IFA 011 [10]. The value in the keyvalue pair indicates the value to be assigned to the MCIO constraint. This attribute shall be present if the granted resources are managed by a CISM. The attribute shall be absent if the granted resources are not managed by a CISM.\n","type":"array","items":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}},"sharedResource":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"vimAssets":{"description":"Information about assets for the VNF that are defined in VNFD and managed by the NFVO in the VIM/NFVI, such as software images and virtualised compute resource flavours. See note 3.\n","type":"object","properties":{"computeResourceFlavours":{"description":"Mappings between virtual compute descriptors defined in the VNFD and compute resource flavours managed in the VIM.\n","type":"array","items":{"description":"If the VIM requires the use of virtual compute resource flavours during compute resource instantiation, it is assumed that such flavours are selected or created by the NFVO based on the information in the virtual compute descriptor defined in the VNFD. This type defines the mapping between a virtual compute descriptor in the VNFD and the corresponding compute resource flavour managed by the NFVO in the VIM.\n","type":"object","required":["vnfdVirtualComputeDescId","vimFlavourId"],"properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfdVirtualComputeDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vimFlavourId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"softwareImages":{"description":"Mappings between software images defined in the VNFD and software images managed in the VIM.\n","type":"array","items":{"description":"This type contains a mapping between a software image definition the VNFD and the corresponding software image managed by the NFVO in the VIM or CIR which is needed during compute resource instantiation.\nNOTE: For an OS container image, the value of this attribute is a string concatenating the name and tag of the image in the CIR separated by a colon ':' with no spaces, e.g. “dbImage:001”.\n","type":"object","required":["vnfdSoftwareImageId","vimSoftwareImageId"],"properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfdSoftwareImageId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vimSoftwareImageId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"snapshotResources":{"description":"Mappings between snapshot resources defined in the VNF snapshot package and resources managed in the VIM.\n","type":"array","items":{"description":"This type contains a mapping between a snapshot resource definition related to a VNF snapshot and the corresponding resource managed by the NFVO in the VIM which is needed during the revert to VNF snapshot operation.\n","type":"object","required":["vnfSnapshotId","vnfcSnapshotId","vimSnapshotResourceId"],"properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfSnapshotId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcSnapshotId":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"storageSnapshotId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"vimSnapshotResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"storageAssets":{"description":"Mappings between virtual storages defined in the VNFD and virtual storages managed in the NFVI.\n","type":"array","items":{"description":"This type provides a mapping between a VirtualStorageDesc in the VNFD and the corresponding virtual storage managed by the NFVO in the NFVI.\n","type":"object","required":["virtualStorageDescId","storageClassName"],"properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"virtualStorageDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"storageClassName":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}}}}},"paasAssets":{"description":"Information about PaaS Services assigned to the VNF and that are managed in the PSM by the NFVO.\n","type":"array","items":{"type":"object","required":["paasServiceType","paasServiceId","paasServiceRequestId","paasServiceHandle"],"properties":{"paasServiceType":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceVersion":{"description":"A version.\n","type":"string"},"paasServiceRequestId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"PaasServiceHandle":{"description":"This type provides information enabling the access and use of the PaaS Service by the VNF instance. The type and format of the handle depends on the form that the PaaS Service is formed.\n","type":"object","required":["id"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}},"extVirtualLinks":{"description":"Information about external VLs to connect the VNF to. See notes 5, 7 and 8. If this attribute is present according to note 5 or note 7, it need not contain those entries that are unchanged compared to the entries that were passed in the LCM operation which is related to this granting exchange.\n","type":"array","items":{"description":"This type represents an external VL.\n* NOTE 1:\tA link port is not needed for an external CP instance that exposes a CP in the following cases:\n 1) For a VIP CP directly exposed as an external CP:\n 1.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD.\n 1.2) A dedicated IP address is allocated as VIP address, but the NFVO indicates that no port is needed\n (createExtLinkPort in VnfExtCpConfig set to false).\n 2) For a VIP CP exposed as an external CP via a floating IP address:\n 2.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD, and the VNFC CP\n associated to the VIP CP is also exposed via a floating IP address.\n 3) For a VIRTUAL CP exposed as an external CP.\n 4) For a VNFC CP exposed as an external CP in a secondary container cluster external network or a\n secondary container cluster internal network.\n\n* NOTE 2: An example of the network attachment definition resource when the container infrastructure service\n management is a Kubernetes® instance is a network attachment definition (NAD).\n* NOTE 3: Either \"extCps\" or “extCpsDeletion\" shall be present, but not both.\n","type":"object","required":["id","resourceId"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"extCps":{"description":"External CPs of the VNF to be connected to this external VL. Entries in the list of external CP data that are unchanged need not be supplied if the ExtVirtualLinkData structure is part of a request or response that modifies the external connectivity. See note 3.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}},"extLinkPorts":{"description":"Externally provided link ports to be used to connect external connection points to this external VL. If this attribute is not present, the VNFM shall create the link ports on the external VL except in the cases defined below. See note 1.\n","type":"array","items":{"description":"This type represents an externally provided link port to be used to connect an external connection point to an external VL. * NOTE:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n","type":"object","required":["id","resourceHandle"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}},"trunkResourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"extNetAttDefResourceData":{"description":"Externally provided network attachment definition resource(s) that provide the specification of the interface to attach external CPs to this external VL. See note 2. It is only applicable if the external VL is realized by a secondary container cluster network. It shall not be present otherwise.\n","type":"array","items":{"description":"This type represents a network attachment definition resource that provides the specification of the interface to be used to connect one or multiple connection points to a secondary container cluster network realizing a VL.\n","type":"object","required":["netAttDefResourceId","resourceHandle"],"properties":{"netAttDefResourceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"extCpsDeletion":{"description":"External CPs of the VNF to be disconnected from this external VL and to be deleted. See note 3.\n","type":"array","items":{"description":"This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n","type":"object","required":["cpdId","cpConfig"],"properties":{"cpdId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"cpConfig":{"description":"Map of instance data that need to be configured on the CP instances created from the respective CPD.\nThe key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the NFVO.\nThe entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3, 4, 5, 6. In case of deleting an external CP, the list of instances to be deleted.\n","type":"object","additionalProperties":{"description":"This type represents an externally provided link port, or a network attachment definition resource of secondary container cluster network, or network address information per instance of an external connection point. In the case of VM-based deployment of the VNFC exposing the external CP: 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the\n external VL.\n 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port\n to connect the external CP to the external VL.\nIn the case of container-based deployment of the VNFC exposing the external CP, the VNFM shall use the network attachment definition resource of secondary container cluster network when connecting the CP to the external VL.\n* NOTE 1: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\" for an external CP instance connected or to be connected to a virtual network not categorized as secondary container cluster network:\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external CP instance\n representing a subport that is to be created, or an external CP instance that is to be created by creating the\n corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing\n external CP instance that is to be re-configured or added to a particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing a\n precreated link port, and the VNFM can use means outside the scope of the present document to obtain the\n pre-configured address information for the connection point from the resource representing the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the NFVO shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n\n* NOTE 2: The following conditions apply to the attributes “netAttDefResourceId” and “cpProtocolData” for an external CP instance connected or to be connected to a secondary container cluster network:\n 1) Void.\n 2) The \"netAttDefResourceId\" attribute shall be present and the \"cpProtocolData\" attribute may be present for\n a to-be-created external CP instance or an existing external CP instance.\n* NOTE 3: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong\n to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" a attribute in the\n \"NetAttDefResourceData\".\n* NOTE 4: Either linkPortId or netAttDefResourceId may be included, but not both.\n","anyOf":[{"required":["linkPortId"]},{"required":["cpProtocolData"]},{"required":["netAttDefResourceId"]}],"type":"object","properties":{"parentCpConfigId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"linkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"createExtLinkPort":{"description":"Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise.\n","type":"boolean"},"netAttDefResourceId":{"description":"Identifier of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the external CP to a secondary container cluster network. It is only applicable if the external CP is connected or to be connected to a secondary container cluster network. It shall not be present if the external CP is related to a virtual network not categorized as secondary container cluster network. See notes 2, 3 and 4.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"cpProtocolData":{"description":"Parameters for configuring the network protocols on the link port that connects the CP to a VL and the domain names for the external CP. See notes 1 and 2.\n","type":"array","items":{"description":"This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n","type":"object","required":["layerProtocol"],"properties":{"layerProtocol":{"description":"Identifier of layer(s) and protocol(s). Permitted values: - IP_OVER_ETHERNET.\n - IP_FOR_VIRTUAL_CP\nSee note\n","type":"string","enum":["IP_OVER_ETHERNET","IP_FOR_VIRTUAL_CP"]},"ipOverEthernet":{"description":"This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n","type":"object","anyOf":[{"required":["macAddress"]},{"required":["ipAddresses"]}],"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"},"segmentationType":{"description":"Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n","type":"string","enum":["VLAN","INHERIT"]},"segmentationId":{"description":"Identification of the network segment to which the CP instance connects to. See note 3 and note 4.\n","type":"string"},"ipAddresses":{"description":"List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1.\n","type":"array","items":{"type":"object","required":["type"],"oneOf":[{"required":["fixedAddresses"]},{"required":["numDynamicAddresses"]},{"required":["addressRange"]}],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"fixedAddresses":{"description":"Fixed addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"array","items":{"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"}},"numDynamicAddresses":{"description":"Number of dynamic addresses to assign (from the subnet defined by \"subnetId\" if provided). See note 2.\n","type":"integer"},"addressRange":{"description":"An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n","type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}},"subnetId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}}}},"virtualCpAddress":{"description":"This type represents network address data for a virtual CP.\n* NOTE 1: The loadBalancerIp and the loadBalancerSourceRanges attributes are only used if the CIS cluster is set up to be able to configure an external load balancer. Otherwise it shall be ignored.\n* NOTE 2: In case the cluster can configure an external load balancer but no loadBalancerIp is provided the container cluster will assign an IP address.\n* NOTE 3: The attribute is only relevant if the virtual CP is instantiated in a cluster that supports configuration of IP address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for\n Kubernetes® that supports configuration of address pools for load balancer services.\n* NOTE 4: The loadBalancerIp, addressPoolName and the externalIp attributes shall not be present at the same time.\n","type":"object","required":["type"],"properties":{"type":{"description":"The type of the IP addresses. Permitted values: IPV4, IPV6.\n","type":"string","enum":["IPV4","IPV6"]},"loadBalancerIp":{"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"},"externalIp":{"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"},"addressPoolName":{"description":"Name of an address pool from which the CIS cluster will assign an IP address to the virtual CP. See notes 3 and 4.\n","type":"string"},"loadBalancerSourceRanges":{"description":"List of client IP address ranges allowed to access an external load balancer. See note 1.\n","type":"array","items":{"type":"object","required":["minAddress","maxAddress"],"properties":{"minAddress":{"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"},"maxAddress":{"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"}}}}}},"fullyQualifiedDomainNames":{"description":"Specifies the fully qualified domain names (FQDN) to apply to the CP.\n","type":"array","items":{"type":"string"}},"relativeDomainNames":{"description":"Specifies values of relative domain names to be considered when setting the fully qualified domain names.\n","type":"array","items":{"type":"string"}}}}},"cpSecurityGroupData":{"description":"This type provides input parameters for modifying and overriding security groups. The parameters identify which \"SecurityGroupRule\" specified in the VNFD is activated/deactivated and for an activated security group rule the values of attributes defined in the VNFD that can be overriden such as \"portRangeMin\" and \"portRangeMax\".\n","type":"object","required":["securityGroupRuleId"],"properties":{"securityGroupRuleId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"isActivated":{"description":"Indicates whether the rule is to be active (true) or inactive (false). If no attribute value is provided, the Security Group Rule is activated by default.\n","type":"boolean"},"portRangeMin":{"description":"Value for the minimum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"},"portRangeMax":{"description":"Value for the maximum port number in the range that is matched by the security group rule. The value shall be within the range \"0 - 65535\".\n","type":"integer"}}}}}}}}}}}},"extManagedVirtualLinks":{"description":"Information about internal VLs that are managed by other entities than the VNFM. See notes 4, 5, 7 and 8.\n","type":"array","items":{"description":"This type represents an externally-managed internal VL.\n* NOTE 1: It is only applicable if the externally-managed VL is realized by a secondary container cluster network. It shall not be present otherwise.\n* NOTE 2: A link port is not needed for a VNFC internal connection point connected to a secondary container cluster network.\n* NOTE 3: An example of the network attachment definition resource when the container infrastructure service management is a Kubernetes® instance is a network attachment definition (NAD).\n\n* NOTE 4: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, an instance of intCp need not be included for each VNFC instance as all instances would contain the same \n information. It is sufficient to include one intCp for the related CPD. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version\n* NOTE 5: Both \"vnfLinkPort\" and \"netAttDefResource\" attributes can be provided in a \"ExtManagedVirtualLinkData\" to indicate that a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs\n","type":"object","required":["id","vnfVirtualLinkDescId","resourceId"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfVirtualLinkDescId":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"netAttDefResourceData":{"description":"Externally provided network attachment definition resource(s) that provide the specification of the interface to attach VNFC connection points to this externallymanaged VL. See notes 1, 3 and 5.\n","type":"array","items":{"description":"This type represents a network attachment definition resource that provides the specification of the interface to be used to connect one or multiple connection points to a secondary container cluster network realizing a VL.\n","type":"object","required":["netAttDefResourceId","resourceHandle"],"properties":{"netAttDefResourceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"intCp":{"description":"Internal CPs of the VNF to be connected to this externally-managed VL. See note 1 and 4.\n","type":"array","items":{"description":"This type represents input information related to one or more VNF internal CP instances created based on the same CPD.\nNOTE: Cardinality greater than 1 is only applicable for specific cases where more than one network attachment definition resource is needed to fulfil the connectivity requirements of the VNF internal CP, e.g. to build a link\n redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall\n belong to the same namespace as defined by the corresponding \"containerNamespace\" attribute in the \"resourceHandle\" attribute\n in the \"NetAttDefResourceData\".\n","type":"object","required":["cpdId","netAttDefResourceId"],"properties":{"cpdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"netAttDefResourceId":{"description":"Identifiers of the “NetAttDefResourceData” structure that provides the specification of the interface to attach the VNF internal CP created from the CPD identified by cpdId to a secondary container cluster network. See note.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}}},"vnfLinkPort":{"description":"Externally provided link ports to be used to connect VNFC connection points to this externally-managed VL on this network resource. If this attribute is not present, the VNFM shall create the link ports on the externally-managed VL. See notes 2 and 5.\n","type":"array","items":{"description":"This type represents an externally provided link port to be used to connect a VNFC connection point to an externally managed VL.\n","type":"object","required":["vnfLinkPortId","resourceHandle"],"properties":{"vnfLinkPortId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceHandle":{"required":["resourceId"],"type":"object","description":"This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n* NOTE 1: The value set of the \"vimLevelResourceType\" attribute is within the scope of the VIM or CISM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from \n the value set of the \"type\" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container \n infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of \n resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, \n e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition.\n\n* NOTE 2: When the container infrastructure service management is a Kubernetes® instance the resourceId shall be populated in the following way:\n - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide \n per resource type.\n - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, \n i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by \n Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own \n manifest.\n - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of \n the 'metadata.name' field in Kubernetes® manifest.\n","properties":{"vimConnectionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceProviderId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"resourceId":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"},"vimLevelResourceType":{"description":"Type of the resource in the scope of the VIM or the CISM or the resource provider. See note 1.\n","type":"string"},"vimLevelAdditionalResourceInfo":{"description":"This type represents additional resource information which resource and resource type specific, and which is available from the VIM or the CISM or the resource provider.\n* NOTE: At least one attribute shall be present.\n","type":"object","properties":{"hostName":{"description":"Name of the host where the resource is allocated. It shall be present for compute resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"persistentVolume":{"description":"Name of the persistent volume to which the persistent volume claim representing the storage resource is bound. It may be present for storage resources in the scope of the CISM and shall be absent otherwise. See note.\n","type":"string"},"additionalInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}},"containerNamespace":{"description":"The value of the namespace in which the MCIO corresponding to the resource is deployed. This attribute shall be present if the resource is managed by a CISM and it shall be absent otherwise.\n","type":"string"}}}}}},"extManagedMultisiteVirtualLinkId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}}}},"additionalParams":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self","vnfLcmOpOcc","vnfInstance"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfLcmOpOcc":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfInstance":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualGrant.Get.202":{"description":"202 ACCEPTED\n\nShall be returned when the process of creating the grant is ongoing, no grant is available yet.\nThe response body shall be empty.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualGrant.Get.403":{"description":"403 FORBIDDEN\n\nShall be returned upon the following error: The grant\nhas been rejected.\nA ProblemDetails structure shall be included in the\nresponse to provide more details about the rejection in\nthe \"details\" attribute.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}} diff --git a/v5.3.1/SOL003-VNFLifecycleOperationGranting-API.yaml b/v5.3.1/SOL003-VNFLifecycleOperationGranting-API.yaml new file mode 100644 index 00000000..957d47f9 --- /dev/null +++ b/v5.3.1/SOL003-VNFLifecycleOperationGranting-API.yaml @@ -0,0 +1,12026 @@ +openapi: 3.0.2 +info: + title: SOL003 - VNF Lifecycle Operation Granting interface + description: | + SOL003 - VNF Lifecycle Operation Granting interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '1.14.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 003 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf +servers: + - url: 'http://127.0.0.1/grant/v1' + - url: 'https://127.0.0.1/grant/v1' +paths: + /api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /grants: + post: + description: > + The POST method requests a grant for a particular VNF lifecycle + operation. See clause 9.4.2.3.1. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/GrantRequest' + responses: + '201': + $ref: '#/components/responses/Grants.Post.201' + '202': + $ref: '#/components/responses/Grants.Post.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/Grants.Post.403' + '404': + description: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/grants/{grantId}': + parameters: + - $ref: '#/components/parameters/GrantId' + get: + description: | + The GET method reads a grant. See clause 9.4.3.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualGrant.Get.200' + '202': + $ref: '#/components/responses/IndividualGrant.Get.202' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/IndividualGrant.Get.403' + '404': + description: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + parameters: + GrantId: + name: grantId + in: path + description: | + Identifier of the grant. + This identifier can be retrieved from the resource referenced by the + "Location" HTTP header in the response to a POST request granting a + new VNF lifecycle operation. It can also be retrieved from the "id" + attribute in the message content of that response. + required: true + style: simple + explode: false + schema: + type: string + requestBodies: + GrantRequest: + content: + application/json: + schema: + description: "This type represents a grant request.\nNOTE 1:\tThe VNF LCM operations CreateVnfIdentifier, DeleteVnfIdentifier, QueryVnf and\n ModifyVnfInformation can be executed by the VNFM without requesting granting.\nNOTE 2: If the granting request is for InstantiateVNF, only one of the three parameters (instantiationLevel or\n targetScaleLevelInfo or addResources) shall be present.\nNOTE 3:\tThe NFVO will assume that the VNFM will be responsible to both allocate and release the temporary\n resource during the runtime of the LCM operation. This means, the resource can be allocated and\n consumed after the \"start\" notification for the LCM operation is sent by the VNFM, and the resource\n will be released before the \"result\" notification of the VNF LCM operation is sent by the VNFM. In the \n case of PaaS Service requests, the handling of the allocation and release of the PaaS Service is a \n responsibility of the NFVO (supported by corresponding PaaS Service management functions) \n based on the information about the progress and completion of the VNF LCM operation.\nNOTE 4:\tFor the affinity/anti-affinity rules defined in the VNFD and the placement constraints in the\n GrantVnfLifecycleOperation as defined in this clause, the following applies: Assuming unlimited\n capacity, the combination of all the aforementioned rules shall be satisfiable by at least one possible\n placement of the new resources, with the exception that some of the rules with fallbackBestEffort\n may be unsatisfiable due to the actual placement of existing resources. In this case, rules with\n fallbackBestEffort are allowed to be violated only in relation to the placement of existing resources.\nNOTE 5:\tPassing constraints allows the VNFM or the lifecycle management scripts to influence resource\n placement decisions by the NFVO to ensure VNF properties such as performance or fault tolerance.\nNOTE 6:\tIf fallbackBestEffort is present and set to \"true\" in one or more placement constraints and the NFVO\n cannot find a resource placement that satisfies all of these due to limited capacity, the NFVO shall\n process each such affinity/antiAffinity constraint in a best effort manner, in which case, if specified\n resources cannot be allocated based on the specified placement constraint, the NFVO shal look for\n an alternate best effort placement for the specified resources to be granted. In the best effort antiaffinity case, the resources are expected to be spread optimally over all available instances of scope\n (e.g. zones), and in the best effort affinity case, they are expected to be distributed optimally over as\n few instances of scope as possible. Being able to satisfy a \"best-effort\" constraint in a best effort\n manner only, as defined above, shall not lead to rejecting the grant.\nNOTE 7: The target size for VNF instantiation may be specified in either instantiationLevelId or\n targetScaleLevelInfo, but not both.\nNOTE 8: If targetScaleLevelInfo is specified, information provided in targetScaleLevelInfo shall be used for\n scalable constituents of the VNF (e.g. VDUs/VLs) in the granting process. For scaling aspects not\n specified in targetScaleLevelInfo or for the VNF constituents (e.g.,VDUs/VLs) that are not scalable,\n the default instantiation level as declared in the VNFD shall be used in the granting process.\nNOTE 9: For resources related to a VDU that has the attribute isNumOfInstancesClusterBased set to TRUE, \n only one occurrence of the addResources, or tempResources or removeResources, or \n updateResources shall be included per descriptor indicated in the resourceTemplateId of the \n ResourceDefinition, not one per VNFC instance.\nNOTE 10: If the granting request is for InstantiateVNF and if there are deployable modules defined in the \n applicable VNF DF in the VNFD, either the selectedDeployableModules attribute or the \n addResource attribute shall be included but not both. If selectedDeployableModules is included, \n either the instantiationLevel or targetScaleLevelInfo attribute shall be also included.\n" + anyOf: + - required: + - instantiationLevelId + - required: + - targetScaleLevelInfo + - required: + - addResources + type: object + required: + - vnfInstanceId + - vnfLcmOpOccId + - vnfdId + - operation + - isAutomaticInvocation + - _links + properties: + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfLcmOpOccId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + dstVnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + flavourId: + description: | + An identifier with the intention of being globally unique. + type: string + operation: + description: > + The enumeration GrantedLcmOperationType defines the permitted + values to represent VNF lifecycle operation types in grant + requests. Value | Description ------|------------ INSTANTIATE + | Represents the "Instantiate VNF" LCM operation. SCALE | + Represents the "Scale VNF" LCM operation. SCALE_TO_LEVEL | + Represents the "Scale VNF to Level" LCM operation. + CHANGE_FLAVOUR | Represents the "Change VNF Flavour" LCM + operation. TERMINATE | Represents the "Terminate VNF" LCM + operation. HEAL | Represents the "Heal VNF" LCM operation. + OPERATE | Represents the "Operate VNF" LCM operation. + CHANGE_EXT_CONN | Represents the "Change external VNF + connectivity" LCM operation. CHANGE_VNFPKG | Represents + the "Change current VNF package" LCM operation. + CREATE_SNAPSHOT | Represents the "Create VNF snapshot" LCM + operation. REVERT_TO_SNAPSHOT | Represents the "Revert to VNF + snapshot" LCM operation. SELECT_DEPL_MODS | Represents the + “Select VNF deployable modules” LCM operation. + type: string + enum: + - INSTANTIATE + - SCALE + - SCALE_TO_LEVEL + - CHANGE_FLAVOUR + - TERMINATE + - HEAL + - OPERATE + - CHANGE_EXT_CONN + - CHANGE_VNFPKG + - CREATE_SNAPSHOT + - REVERT_TO_SNAPSHOT + - SELECT_DEPL_MODS + isAutomaticInvocation: + description: > + Set to true if this VNF LCM operation occurrence has been + triggered by an automated procedure inside the VNFM (i.e. + ScaleVnf / ScaleVnfToLevel triggered by auto-scale, or HealVnf + triggered by auto-heal). Set to false otherwise. + type: boolean + instantiationLevelId: + description: | + An identifier with the intention of being globally unique. + type: string + targetScaleLevelInfo: + description: > + This attribute shall only be used for Instantiate VNF + requests. This is applicable if VNF supports target scale + level instantiation. + + This attribute provides an alternative way to define the + resources to be added for the VNFs. + + For each scaling aspect of the current deployment flavour, the + attribute specifies the scale level of VNF constituents (e.g., + VDU level) to be instantiated. See notes 2, 7, 8 and 10. + type: array + items: + description: > + This type represents the scale level of a VNF instance + related to a scaling aspect. + type: object + required: + - aspectId + - scaleLevel + properties: + aspectId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + scaleToLevel: + description: > + An identifier with the intention of being globally + unique. + type: string + selectedDeployableModule: + description: > + References a selected deployable module. Resources related to + VDUs that belong to not selected deployable modules shall not + be considered in the granting + + This attribute shall only be used for the instantiate VNF + request. See note 10. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + resourceCapacityDefinition: + description: > + Indicates values for resource capacity related attributes + pertaining to a descriptor, as received in the VNF LCM + operation request. The values indicated in this attribute are + applicable to all VNFC instances based on the VDU to which + the resourceCapacityDefinition is related. + type: array + items: + description: > + This type represents selected values for capacity related + VDU attributes. + + * NOTE: Resource definitions not related to a VDU are not + considered in this version of the present document. + type: object + required: + - type + properties: + tag: + description: > + Tag assigned by the issuer of a VNF LCM operation + request that contains this data type with values to be + applied to a VDU. It is used for tracking purposes. + + The tag is preserved in the run time record as long as + at least one value of the capacity related attributes + associated with that tag is still valid, i.e., it has + not been modified by a later VNF LCM operation request. + + At most one tag can be included when the data type is + used in a VNF LCM operation request. + + When the data type is used in the VnfInstance data type + it may contain multiple tags, namely those provided in + VNF LCM requests, if at least one of the values provided + in that request associated to that tag is still + applicable in the VNFCs created from this VDU, i.e., it + has not been modified by a later request. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + type: + description: | + Type of the resource definition referenced. + type: string + enum: + - COMPUTE + - STORAGE + - OSCONTAINER + vduId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + osContainerDescData: + description: > + Indicates values for resource capacity related + attributes in an OsContainerDesc. It shall be present + when the attribute 'type' indicates OSCONTAINER and + absent otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of an OsContainer resource. + + * NOTE: At least one of the attributes shall be + present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - requestedCpuResources + - required: + - requestedMemoryResources + - required: + - requestedEphemeralStorageResources + - required: + - extendedResourceRequests + - required: + - cpuResourceLimit + - required: + - memoryResourceLimit + - required: + - ephemeralStorageResourceLimit + - required: + - hugePageResources + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for the + container in milli-CPU. See note. + type: integer + requestedMemoryResources: + description: > + Amount of memory resources requested for the + container expressed in the same units as + specified in the + requested_memory_resources_valid_values property + in VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 + [14]) for this container descriptor. See note. + type: array + items: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + Map of the amount of extended resources of the + type indicated in the key. The key is a string + that identifies an extended resource indicated in + the extended_resource_requests property in the + VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 [14]) + for this container descriptor. The value is an + integer that indicates the required amount for a + particular extended resource. See note. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container can + maximally use in milli-CPU. See note. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Map of the total size values required for all the + hugepages of the size indicated in the key. The + key is a string and corresponds to one of the + values of the hugepage sizes indicated in the + huge_pages_resources property in the VNFD (clause + 6.8.12 in ETSI GS NFV-SOL 001 [14]) for this + container descriptor. The value is a number that + indicates the required total size expressed in the + same units as in the huge_pages_resource property + in the VNFD (clause 6.8.12 in ETSI GS NFV-SOL 001 + [14]) that indicates the valid values for required + total size for the particular hugepage size. See + note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores are + requested to be allocated to logical CPU cores + according to the cpuOperationalPowerStates + attribute. In case of "DYNAMIC", the CPU power + states of virtual CPU cores can be allocated + to logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause 4 + of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys + ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be + of different type. + type: object + virtualComputeDescData: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual compute resource + of a VM. + + * NOTE: At least one of the attributes shall be present. + type: object + required: + - resourceTemplateId + oneOf: + - required: + - numVirtualCpu + - required: + - virtualMemSize + - required: + - sizeOfVirtualDisk + - required: + - hugePagesRequirements + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + numVirtualCpu: + description: | + Number of virtual CPUs. See note. + type: integer + virtualMemSize: + description: | + A number defined in IETF RFC 8259. + type: number + sizeOfVirtualDisk: + description: | + A number defined in IETF RFC 8259. + type: number + hugePagesRequirements: + description: > + Map of the total size values required for all the + hugepages of the size indicated in the key. The key + is a string and corresponds to one of the values of + the hugepage sizes indicated in the + huge_pages_requirements property in the VNFD (clause + 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) for this + virtual compute descriptor. The value is a + numberthat indicates the required total size + expressed in the same units as in the + huge_pages_requirements property in the VNFD (clause + 6.2.7.2 in ETSI GS NFV-SOL 001 [14]) that indicates + the valid vaues for required total size for the + particular hugepage size. See note. + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + cpuPowerStateRequirements: + description: > + This type provides virtual CPU power state + configuration data for the virtual compute or OS + container resource. + + * NOTE 1: In case the value of the + cpuPowerStateManagementPolicy attribute + is "DYNAMIC", dynamic adjustment of CPU power states of logical CPU cores + should adhere to the range of CPU P and C states defined in the + cpuOperationalPowerStates attribute. + * NOTE 2: In case the value of the + cpuPowerStateManagementPolicy attribute + is "STATIC", the cpuOperationalPowerStates attribute shall contain only + one set of CPU P and C states requested for the virtual CPU. + If the value of the cpuPowerStateManagementPolicy attribute is + "DYNAMIC", multiple CPU P and C states can be defined to indicate the + range of allowed P/C state values during dynamic power state management. + type: object + required: + - cpuPowerStateManagementPolicy + properties: + cpuPowerStateManagementPolicy: + description: > + Indicates the policy for CPU power state + management. Permitted values: + * STATIC + * DYNAMIC + In case of "STATIC", the virtual CPU cores are + requested to be allocated to logical CPU cores + according to the cpuOperationalPowerStates + attribute. In case of "DYNAMIC", the CPU power + states of virtual CPU cores can be allocated to + logical CPU cores whose power states can be + adjusted dynamically depending on core + utilization (see note 1). + type: string + enum: + - STATIC + - DYNAMIC + cpuOperationalPowerStates: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + virtualStorageDescData: + description: > + Indicates the value for the storage size related + attribute in an VirtualStorageDesc. It shall be present + when the attribute 'type' indicates STORAGE and absent + otherwise. + type: array + items: + description: > + This type represents selected values for capacity + related VDU attributes of the virtual storage + resource. + type: object + required: + - resourceTemplateId + - sizeOfStorage + properties: + resourceTemplateId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + sizeOfStorage: + description: | + A number defined in IETF RFC 8259. + type: number + addResources: + description: > + List of resource definitions in the VNFD for resources to be + added by the LCM operation which is related to this grant + request, with one entry per resource. See notes 2, 9 and 10. + type: array + items: + description: "This type provides information of an existing or proposed resource or PaaS Service used by the VNF.\nNOTE 1:\tThe use cases UC#4 and UC#5 in Annex A.4 of ETSI GS NFV-IFA 007 provide examples\n for such a configuration.\nNOTE 2:\tIn the context of an operation that changes the current VNF package, the following applies: If this\n ResourceDefinition is related to a resource to be created or modified, the \"vnfdId\" attribute shall\n contain the identifier of the destination VNFD. If this ResourceDefinition is related to a resource\n to be deleted, the \"vnfdId\" attribute shall contain the identifier of the source VNFD. If this\n ResourceDefinition is related to a temporary resource, the \"vnfdId\" attribute shall contain the\n identifier of either the source VNFD or the destination VNFD.\nNOTE 3: In case of the type of the ResourceDefinition is \"OSCONTAINER\", either \n resourceTemplateId or osContainerDesc shall be present.\nNOTE 4: In case the osContainerDesc is not present in the VNFD, while MCIOP(s) is present, \n osContainerDesc shall be included in the GrantVnfLifecycleOperationRequest based on \n the processing result of the MCIOP from CISM.\n" + type: object + oneOf: + - required: + - resourceTemplateId + - required: + - osContainerDesc + required: + - id + - type + properties: + id: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + type: + description: > + Type of the resource definition referenced. Permitted + values: * COMPUTE * VL * STORAGE * LINKPORT * + OSCONTAINER * VIRTUALCP * PAASSERVICE + type: string + enum: + - COMPUTE + - VL + - STORAGE + - LINKPORT + - OSCONTAINER + - VIRTUALCP + - PAASSERVICE + vduId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceTemplateId: + description: > + Reference to the applicable resource template in the + VNFD as follows: + - if type="VL" : VnfVirtualLinkDesc + - if type="COMPUTE": VirtualComputeDesc + - if type="LINKPORT" : VnfExtCpd + - if type="STORAGE" : VirtualStorageDesc + - If type="OSCONTAINER": OsContainerDesc + - If type="VIRTUALCP": VirtualCpd + - If type="PAASSERVICE": PaasServiceRequest + Cardinality may be greater than "1" when + type="OSCONTAINER" and multiple references to + OsContainerDesc are present in the VDU indicated by the + "vduId". See note 3. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + osContainerDesc: + description: > + Resource requirements for the OS Containers. See note 3 + and 4. + type: array + items: + description: > + This type describes the properties of a set of + co-located container compute resources required for + realizing a VDU. + type: object + required: + - osContainerDescId + - name + - description + properties: + osContainerDescId: + description: > + An identifier with the intention of being globally + unique. + type: string + name: + description: | + A string defined in IETF RFC 8259. + type: string + description: + description: | + A string defined in IETF RFC 8259. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for the + container (e.g. in milli-CPU-s). + type: integer + requestedMemoryResources: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + An array of key-value pairs of extended resources + required by the container. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container can + maximally use in milli-CPU. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Specifies HugePages resources requested for the + container, which the container can maximally use + (e.g. "hugepages-2Mi: 100Mi"). + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + secondaryResourceTemplateId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + resource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + snapshotResDef: + description: "This type represents resource definition information related to a snapshot resource.\nNOTE 1:\tIf present, the value of the \"vduId\" (for a related VDU) in the \"VnfcResourceInfo\" \n referred by the \"vnfcInfoId\" of the \"VnfcSnapshotInfo\" shall match the value of the \n \"vduId\" in the resource definition that is signalled in the granting request.\nNOTE 2:\tFor snapshot resource definitions extracted from a VNF snapshot package, only the \n \"vnfcSnapshotId\" and \"storageSnapshotId\" (in case of a storage type of resource) \n are applicable. If the snapshot resource definition is generated as part of a VNF \n snapshot created by the VNFM (that is, not extracted from a VNF snapshot package), \n the \"snapshotResource\" is applicable. This is a similar specification as the one \n defined with the \"vduId\", \"resourceTemplateId\" and \"resource\" attributes provided in \n the ResourceDefinition, but in this case applicable to resources that are defined from \n VNF snapshots instead of VNFD.\n" + type: object + required: + - vnfSnapshotId + properties: + vnfSnapshotId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfcSnapshotId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + storageSnapshotId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + snapshotResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + resourceUsageRequirement: + description: > + The type of resource usage requirement. A resource can + be shared among VNF instances or dedicated to a single + VNF instance. Permitted values: + DEDICATED + SHARED + Default value is "DEDICATED". + type: string + enum: + - DEDICATED + - SHARED + tempResources: + description: > + List of resource definitions in the VNFD for resources to be + temporarily instantiated during the runtime of the LCM + operation which is related to this grant request, with one + entry per resource. See notes 3 and 9. + type: array + items: + description: "This type provides information of an existing or proposed resource or PaaS Service used by the VNF.\nNOTE 1:\tThe use cases UC#4 and UC#5 in Annex A.4 of ETSI GS NFV-IFA 007 provide examples\n for such a configuration.\nNOTE 2:\tIn the context of an operation that changes the current VNF package, the following applies: If this\n ResourceDefinition is related to a resource to be created or modified, the \"vnfdId\" attribute shall\n contain the identifier of the destination VNFD. If this ResourceDefinition is related to a resource\n to be deleted, the \"vnfdId\" attribute shall contain the identifier of the source VNFD. If this\n ResourceDefinition is related to a temporary resource, the \"vnfdId\" attribute shall contain the\n identifier of either the source VNFD or the destination VNFD.\nNOTE 3: In case of the type of the ResourceDefinition is \"OSCONTAINER\", either \n resourceTemplateId or osContainerDesc shall be present.\nNOTE 4: In case the osContainerDesc is not present in the VNFD, while MCIOP(s) is present, \n osContainerDesc shall be included in the GrantVnfLifecycleOperationRequest based on \n the processing result of the MCIOP from CISM.\n" + type: object + oneOf: + - required: + - resourceTemplateId + - required: + - osContainerDesc + required: + - id + - type + properties: + id: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + type: + description: > + Type of the resource definition referenced. Permitted + values: * COMPUTE * VL * STORAGE * LINKPORT * + OSCONTAINER * VIRTUALCP * PAASSERVICE + type: string + enum: + - COMPUTE + - VL + - STORAGE + - LINKPORT + - OSCONTAINER + - VIRTUALCP + - PAASSERVICE + vduId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceTemplateId: + description: > + Reference to the applicable resource template in the + VNFD as follows: + - if type="VL" : VnfVirtualLinkDesc + - if type="COMPUTE": VirtualComputeDesc + - if type="LINKPORT" : VnfExtCpd + - if type="STORAGE" : VirtualStorageDesc + - If type="OSCONTAINER": OsContainerDesc + - If type="VIRTUALCP": VirtualCpd + - If type="PAASSERVICE": PaasServiceRequest + Cardinality may be greater than "1" when + type="OSCONTAINER" and multiple references to + OsContainerDesc are present in the VDU indicated by the + "vduId". See note 3. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + osContainerDesc: + description: > + Resource requirements for the OS Containers. See note 3 + and 4. + type: array + items: + description: > + This type describes the properties of a set of + co-located container compute resources required for + realizing a VDU. + type: object + required: + - osContainerDescId + - name + - description + properties: + osContainerDescId: + description: > + An identifier with the intention of being globally + unique. + type: string + name: + description: | + A string defined in IETF RFC 8259. + type: string + description: + description: | + A string defined in IETF RFC 8259. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for the + container (e.g. in milli-CPU-s). + type: integer + requestedMemoryResources: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + An array of key-value pairs of extended resources + required by the container. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container can + maximally use in milli-CPU. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Specifies HugePages resources requested for the + container, which the container can maximally use + (e.g. "hugepages-2Mi: 100Mi"). + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + secondaryResourceTemplateId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + resource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + snapshotResDef: + description: "This type represents resource definition information related to a snapshot resource.\nNOTE 1:\tIf present, the value of the \"vduId\" (for a related VDU) in the \"VnfcResourceInfo\" \n referred by the \"vnfcInfoId\" of the \"VnfcSnapshotInfo\" shall match the value of the \n \"vduId\" in the resource definition that is signalled in the granting request.\nNOTE 2:\tFor snapshot resource definitions extracted from a VNF snapshot package, only the \n \"vnfcSnapshotId\" and \"storageSnapshotId\" (in case of a storage type of resource) \n are applicable. If the snapshot resource definition is generated as part of a VNF \n snapshot created by the VNFM (that is, not extracted from a VNF snapshot package), \n the \"snapshotResource\" is applicable. This is a similar specification as the one \n defined with the \"vduId\", \"resourceTemplateId\" and \"resource\" attributes provided in \n the ResourceDefinition, but in this case applicable to resources that are defined from \n VNF snapshots instead of VNFD.\n" + type: object + required: + - vnfSnapshotId + properties: + vnfSnapshotId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfcSnapshotId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + storageSnapshotId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + snapshotResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + resourceUsageRequirement: + description: > + The type of resource usage requirement. A resource can + be shared among VNF instances or dedicated to a single + VNF instance. Permitted values: + DEDICATED + SHARED + Default value is "DEDICATED". + type: string + enum: + - DEDICATED + - SHARED + removeResources: + description: > + Provides the definitions of resources to be removed by the LCM + operation which is related to this grant request, with one + entry per resource. See note 9. + type: array + items: + description: "This type provides information of an existing or proposed resource or PaaS Service used by the VNF.\nNOTE 1:\tThe use cases UC#4 and UC#5 in Annex A.4 of ETSI GS NFV-IFA 007 provide examples\n for such a configuration.\nNOTE 2:\tIn the context of an operation that changes the current VNF package, the following applies: If this\n ResourceDefinition is related to a resource to be created or modified, the \"vnfdId\" attribute shall\n contain the identifier of the destination VNFD. If this ResourceDefinition is related to a resource\n to be deleted, the \"vnfdId\" attribute shall contain the identifier of the source VNFD. If this\n ResourceDefinition is related to a temporary resource, the \"vnfdId\" attribute shall contain the\n identifier of either the source VNFD or the destination VNFD.\nNOTE 3: In case of the type of the ResourceDefinition is \"OSCONTAINER\", either \n resourceTemplateId or osContainerDesc shall be present.\nNOTE 4: In case the osContainerDesc is not present in the VNFD, while MCIOP(s) is present, \n osContainerDesc shall be included in the GrantVnfLifecycleOperationRequest based on \n the processing result of the MCIOP from CISM.\n" + type: object + oneOf: + - required: + - resourceTemplateId + - required: + - osContainerDesc + required: + - id + - type + properties: + id: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + type: + description: > + Type of the resource definition referenced. Permitted + values: * COMPUTE * VL * STORAGE * LINKPORT * + OSCONTAINER * VIRTUALCP * PAASSERVICE + type: string + enum: + - COMPUTE + - VL + - STORAGE + - LINKPORT + - OSCONTAINER + - VIRTUALCP + - PAASSERVICE + vduId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceTemplateId: + description: > + Reference to the applicable resource template in the + VNFD as follows: + - if type="VL" : VnfVirtualLinkDesc + - if type="COMPUTE": VirtualComputeDesc + - if type="LINKPORT" : VnfExtCpd + - if type="STORAGE" : VirtualStorageDesc + - If type="OSCONTAINER": OsContainerDesc + - If type="VIRTUALCP": VirtualCpd + - If type="PAASSERVICE": PaasServiceRequest + Cardinality may be greater than "1" when + type="OSCONTAINER" and multiple references to + OsContainerDesc are present in the VDU indicated by the + "vduId". See note 3. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + osContainerDesc: + description: > + Resource requirements for the OS Containers. See note 3 + and 4. + type: array + items: + description: > + This type describes the properties of a set of + co-located container compute resources required for + realizing a VDU. + type: object + required: + - osContainerDescId + - name + - description + properties: + osContainerDescId: + description: > + An identifier with the intention of being globally + unique. + type: string + name: + description: | + A string defined in IETF RFC 8259. + type: string + description: + description: | + A string defined in IETF RFC 8259. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for the + container (e.g. in milli-CPU-s). + type: integer + requestedMemoryResources: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + An array of key-value pairs of extended resources + required by the container. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container can + maximally use in milli-CPU. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Specifies HugePages resources requested for the + container, which the container can maximally use + (e.g. "hugepages-2Mi: 100Mi"). + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + secondaryResourceTemplateId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + resource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + snapshotResDef: + description: "This type represents resource definition information related to a snapshot resource.\nNOTE 1:\tIf present, the value of the \"vduId\" (for a related VDU) in the \"VnfcResourceInfo\" \n referred by the \"vnfcInfoId\" of the \"VnfcSnapshotInfo\" shall match the value of the \n \"vduId\" in the resource definition that is signalled in the granting request.\nNOTE 2:\tFor snapshot resource definitions extracted from a VNF snapshot package, only the \n \"vnfcSnapshotId\" and \"storageSnapshotId\" (in case of a storage type of resource) \n are applicable. If the snapshot resource definition is generated as part of a VNF \n snapshot created by the VNFM (that is, not extracted from a VNF snapshot package), \n the \"snapshotResource\" is applicable. This is a similar specification as the one \n defined with the \"vduId\", \"resourceTemplateId\" and \"resource\" attributes provided in \n the ResourceDefinition, but in this case applicable to resources that are defined from \n VNF snapshots instead of VNFD.\n" + type: object + required: + - vnfSnapshotId + properties: + vnfSnapshotId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfcSnapshotId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + storageSnapshotId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + snapshotResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + resourceUsageRequirement: + description: > + The type of resource usage requirement. A resource can + be shared among VNF instances or dedicated to a single + VNF instance. Permitted values: + DEDICATED + SHARED + Default value is "DEDICATED". + type: string + enum: + - DEDICATED + - SHARED + updateResources: + description: > + Provides the definitions of resources to be modified by the + LCM operation which is related to this grant request, with one + entry per resource. See note 9. + type: array + items: + description: "This type provides information of an existing or proposed resource or PaaS Service used by the VNF.\nNOTE 1:\tThe use cases UC#4 and UC#5 in Annex A.4 of ETSI GS NFV-IFA 007 provide examples\n for such a configuration.\nNOTE 2:\tIn the context of an operation that changes the current VNF package, the following applies: If this\n ResourceDefinition is related to a resource to be created or modified, the \"vnfdId\" attribute shall\n contain the identifier of the destination VNFD. If this ResourceDefinition is related to a resource\n to be deleted, the \"vnfdId\" attribute shall contain the identifier of the source VNFD. If this\n ResourceDefinition is related to a temporary resource, the \"vnfdId\" attribute shall contain the\n identifier of either the source VNFD or the destination VNFD.\nNOTE 3: In case of the type of the ResourceDefinition is \"OSCONTAINER\", either \n resourceTemplateId or osContainerDesc shall be present.\nNOTE 4: In case the osContainerDesc is not present in the VNFD, while MCIOP(s) is present, \n osContainerDesc shall be included in the GrantVnfLifecycleOperationRequest based on \n the processing result of the MCIOP from CISM.\n" + type: object + oneOf: + - required: + - resourceTemplateId + - required: + - osContainerDesc + required: + - id + - type + properties: + id: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + type: + description: > + Type of the resource definition referenced. Permitted + values: * COMPUTE * VL * STORAGE * LINKPORT * + OSCONTAINER * VIRTUALCP * PAASSERVICE + type: string + enum: + - COMPUTE + - VL + - STORAGE + - LINKPORT + - OSCONTAINER + - VIRTUALCP + - PAASSERVICE + vduId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceTemplateId: + description: > + Reference to the applicable resource template in the + VNFD as follows: + - if type="VL" : VnfVirtualLinkDesc + - if type="COMPUTE": VirtualComputeDesc + - if type="LINKPORT" : VnfExtCpd + - if type="STORAGE" : VirtualStorageDesc + - If type="OSCONTAINER": OsContainerDesc + - If type="VIRTUALCP": VirtualCpd + - If type="PAASSERVICE": PaasServiceRequest + Cardinality may be greater than "1" when + type="OSCONTAINER" and multiple references to + OsContainerDesc are present in the VDU indicated by the + "vduId". See note 3. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + osContainerDesc: + description: > + Resource requirements for the OS Containers. See note 3 + and 4. + type: array + items: + description: > + This type describes the properties of a set of + co-located container compute resources required for + realizing a VDU. + type: object + required: + - osContainerDescId + - name + - description + properties: + osContainerDescId: + description: > + An identifier with the intention of being globally + unique. + type: string + name: + description: | + A string defined in IETF RFC 8259. + type: string + description: + description: | + A string defined in IETF RFC 8259. + type: string + requestedCpuResources: + description: > + Number of CPU resources requested for the + container (e.g. in milli-CPU-s). + type: integer + requestedMemoryResources: + description: | + A number defined in IETF RFC 8259. + type: number + requestedEphemeralStorageResources: + description: | + A number defined in IETF RFC 8259. + type: number + extendedResourceRequests: + description: > + An array of key-value pairs of extended resources + required by the container. + type: object + additionalProperties: + type: integer + cpuResourceLimit: + description: > + Number of CPU resources the container can + maximally use in milli-CPU. + type: integer + memoryResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + ephemeralStorageResourceLimit: + description: | + A number defined in IETF RFC 8259. + type: number + hugePageResources: + description: > + Specifies HugePages resources requested for the + container, which the container can maximally use + (e.g. "hugepages-2Mi: 100Mi"). + type: object + additionalProperties: + description: | + A number defined in IETF RFC 8259. + type: number + secondaryResourceTemplateId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + resource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + snapshotResDef: + description: "This type represents resource definition information related to a snapshot resource.\nNOTE 1:\tIf present, the value of the \"vduId\" (for a related VDU) in the \"VnfcResourceInfo\" \n referred by the \"vnfcInfoId\" of the \"VnfcSnapshotInfo\" shall match the value of the \n \"vduId\" in the resource definition that is signalled in the granting request.\nNOTE 2:\tFor snapshot resource definitions extracted from a VNF snapshot package, only the \n \"vnfcSnapshotId\" and \"storageSnapshotId\" (in case of a storage type of resource) \n are applicable. If the snapshot resource definition is generated as part of a VNF \n snapshot created by the VNFM (that is, not extracted from a VNF snapshot package), \n the \"snapshotResource\" is applicable. This is a similar specification as the one \n defined with the \"vduId\", \"resourceTemplateId\" and \"resource\" attributes provided in \n the ResourceDefinition, but in this case applicable to resources that are defined from \n VNF snapshots instead of VNFD.\n" + type: object + required: + - vnfSnapshotId + properties: + vnfSnapshotId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfcSnapshotId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + storageSnapshotId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + snapshotResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a + VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the scope + of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or + the CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM or + the CISM or the resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall + be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be present + for storage resources in the scope of the + CISM and shall be absent otherwise. See + note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list is + not significant. In JSON, a set of keyvalue + pairs is represented as an object. It shall + comply with the provisions defined in clause + 4 of IETF RFC 8259. In the following + example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that + the values associated with different keys + can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent + otherwise. + type: string + resourceUsageRequirement: + description: > + The type of resource usage requirement. A resource can + be shared among VNF instances or dedicated to a single + VNF instance. Permitted values: + DEDICATED + SHARED + Default value is "DEDICATED". + type: string + enum: + - DEDICATED + - SHARED + placementConstraints: + description: > + Placement constraints that the VNFM may send to the NFVO in + order to influence the resource placement decision. If sent, + the NFVO shall take the constraints into consideration when + making resource placement decisions and shall reject the + grant if they cannot be honoured. See notes 4, 5 and 6. + type: array + items: + description: > + This type provides information regarding a resource + placement constraint. A set of such constraints may be sent + by the VNFM to the NFVO to influence the resource placement + decisions made by the NFVO as part of the granting process. + A placement constraint defines a condition to the placement + of new resources, considering other new resources as well as + existing resources. EXAMPLE: The following rules influence + the placement of a set of resources such that they are + placed in the same Network Function Virtualisation + Infrastructure Point of Presence (NFVI-PoP) but in different + resource zones: {type="AFFINITY"; scope="NFVI_POP"; + {resource1,resource2}} {type="ANTI_AFFINITY"; scope="ZONE"; + {resource1,resource2}} + + Annex B in ETSI GS NFV-IFA 011 [10] provides additional + description and examples about the usage of the + affinity/anti-affinity rules. + + + NOTE: The "CIS_NODE" and “CONTAINER_NAMESPACE” scopes shall + only be used to express affinity or + antiaffinity relationship between containerized workloads. + type: object + required: + - affinityOrAntiAffinity + - scope + - resource + properties: + affinityOrAntiAffinity: + description: > + The type of the constraint. Permitted values: * AFFINITY + * ANTI_AFFINITY + type: string + enum: + - AFFINITY + - ANTI_AFFINITY + scope: + description: > + The scope of the placement constraint indicating the + category of the "place" where the constraint applies. + Permitted values: + - NFVI_POP + - ZONE + - ZONE_GROUP + - NFVI_NODE + - CIS_NODE + - CONTAINER_NAMESPACE + - See note. + type: string + enum: + - NFVI_POP + - ZONE + - ZONE_GROUP + - NFVI_NODE + - CIS_NODE + - CONTAINER_NAMESPACE + resource: + description: | + References to resources in the constraint rule. + type: array + minItems: 2 + items: + description: > + This type references a resource either by its + VIM-level identifier for existing resources, or by the + identifier of a "ResourceDefinition" structure in the + "GrantRequest" structure for new resources. + type: object + required: + - idType + - resourceId + properties: + idType: + description: > + The type of the identifier. Permitted values: * + RES_MGMT: Resource-management-level identifier; + this identifier is + managed by the VIM in the direct mode of VNF-related resource + management, and is managed by the NFVO in the indirect mode) + * GRANT: Reference to the identifier of a + "ResourceDefinition" structure in the + "GrantRequest" structure. + type: string + enum: + - RES_MGMT + - GRANT + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + fallbackBestEffort: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + vimConstraints: + description: > + Used by the VNFM to require that multiple resources are + managed through the same VIM connection. If sent, the NFVO + shall take the constraints into consideration when making VIM + selection decisions, and shall reject the grant if they cannot + be honoured. This attribute shall be supported if VNF-related + Resource Management in direct mode is applicable. The + applicability and further details of this attribute for + indirect mode are left for future specification. + type: array + items: + description: > + This type provides information regarding a VIM selection + constraint. A set of such constraints may be sent by the + VNFM to the NFVO to influence the VIM selection decisions + made by the NFVO as part of the granting process. + type: object + required: + - resource + properties: + sameResourceGroup: + description: > + If present and set to true, this signals that the + constraint applies not only to the same VIM connection, + but also to the same infrastructure resource group. + type: boolean + resource: + description: > + References to resources in the constraint rule. The NFVO + shall ensure that all resources in this list are managed + through the same VIM connection. If "sameResourceGroup" + is set to true, the NFVO shall further ensure that all + resources in this list are part of the same + infrastructure resource group in that VIM connection. + type: array + minItems: 2 + items: + description: > + This type references a resource either by its + VIM-level identifier for existing resources, or by the + identifier of a "ResourceDefinition" structure in the + "GrantRequest" structure for new resources. + type: object + required: + - idType + - resourceId + properties: + idType: + description: > + The type of the identifier. Permitted values: * + RES_MGMT: Resource-management-level identifier; + this identifier is + managed by the VIM in the direct mode of VNF-related resource + management, and is managed by the NFVO in the indirect mode) + * GRANT: Reference to the identifier of a + "ResourceDefinition" structure in the + "GrantRequest" structure. + type: string + enum: + - RES_MGMT + - GRANT + resourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + _links: + description: | + Links to resources related to this request. + type: object + required: + - vnfLcmOpOcc + - vnfInstance + properties: + vnfLcmOpOcc: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + responses: + Grants.Post.201: + description: > + 201 CREATED + + + Shall be returned when the grant has been created successfully + (synchronous mode). + + A representation of the created "Individual grant" resource shall be + returned in the response body. + + The HTTP response shall include a "Location" HTTP header that indicates + the URI of the "Individual grant" + + resource just created. + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: "This type represents a grant.\nNOTE 1: This interface allows to signal the use of multiple VIMs per VNF. The specification\n for managing the VNF internal VL requirements across multiple VIMs is supported via\n \"externally-managed internal VLs\" and \"multi-site connectivity services\".\nNOTE 2: Void. NOTE 3: The Grant response allows the NFVO to pass to the VNFM VIM assets related to the VNF \n package that is identified in the corresponding Grant request. Because only the operations\n InstantiateVnf, ChangeCurrentVnfPkg and the update of the vnfdId by PATCH can imply changes\n in the set of VIM assets, the NFVO shall not change this set in any other case. To signal the\n set of VIM assets, the following applies:\n a)\tIf the current LCM operation is InstantiateVnf, the NFVO shall send in the Grant response\n the full set of VIM assets related to the VNF package defined by the vnfdId in the related\n Grant request.\n b)\tIf the current LCM operation is ChangeCurrentVnfPkg, the NFVO shall send in the\n Grant response the full set of VIM assets related to the VNF package defined by the destVnfdId\n in the related Grant request.\n c)\tFor any other operation: If the set of VIM assets has changed since the end of the previous\n granted operation because a PATCH operation has changed the vnfdId between the previous granted\n operation and the operation to which the current granting exchange relates, the NFVO shall send\n in the Grant response the full set of VIM assets related to the VNF package defined by the vnfdId\n in the related Grant request. Otherwise, the NFVO shall either send in the Grant response the full\n set of VIM assets related to the VNF package defined by the vnfdId in the related Grant request, or\n shall not send any VIM assets at all.\n During each LCM operation occurrence other than a \"ChangeCurrentVnfPkg\" operation,\n the VIM assets that relate to the VNF package identified by the current value of\n the vnfdId attribute in the \"VnfInstance\" structure shall be used by the\n VNFM for newly created resources and updated resources.\nNOTE 4: The indication of externally-managed internal VLs is needed in case networks have been\n pre-configured for use with certain VNFs, for instance to ensure that these networks have\n certain properties such as security or acceleration features, or to address particular network\n topologies (e.g., multi-site connectivity). The present document assumes that externally-managed\n internal VLs are managed by the NFVO and created towards the VIM and WIM.\nNOTE 5: For any VNF lifecycle management operation request that allows to pass \"extVirtualLinks\" and/or\n \"extManagedVirtualLinks\" parameters, such as InstantiateVnf, ChangeVnfFlavour, ChangeExtVnfConnectivity or\n ChangeCurrentVnfPackage, the NFVO may provide the \"extVirtualLinks\" and/or \"extManagedVirtualLinks\" attributes\n in the Grant to override the values passed in these parameters previously in the associated VNF lifecycle\n management request, if the lifecycle management request has originated from the NFVO itself. The NFVO shall\n not provide the \"extVirtualLinks\" and/or \"extManagedVirtualLinks\" attributes in the Grant in case the LCM\n request did not originate from the NFVO itself or the granted LCM operation request does not allow to pass\n these parameters.\nNOTE 6: The NFVO shall set the value of the attribute by copying the value from the associated \n GrantRequest.\nNOTE 7: In case of granting an InstantiateVnf request that has originated from the NFVO and that \n did not contain the \"extVirtualLinks\" attribute, this attribute shall be set by the NFVO. \n Further in case of granting an InstantiateVnf request that has originated from the NFVO \n and that did not contain the \"extManagedVirtualLinks\" attribute, this attribute shall be \n set by the NFVO if there is the need to provide information about externally-managed virtual \n links.\nNOTE 8: The resulting \"extVirtualLinks\" or \"extManagedVirtualLinks\" information is calculated as follows: \n In a first step, the information passed in the related LCM operation is applied to the baseline\n information known from earlier LCM operation executions. In a second step, the information passed\n in the Grant is applied to the information resulting from the first step.\nNOTE 9: For resources related to ResourceDefinition whose VDU has the attribute \n isNumOfInstancesClusterBased set to TRUE, only one occurrence of the addResources, or \n tempResources or removeResources, or updateResources shall be included.\n" + type: object + required: + - id + - vnfInstanceId + - vnfLcmOpOccId + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfLcmOpOccId: + description: | + An identifier with the intention of being globally unique. + type: string + vimConnectionInfo: + description: > + Provides information regarding VIM and/or CISM connections + that are approved to be used by the VNFM to allocate resources + and provides parameters of these VIM and/or CISM connections. + The VNFM shall update the "vimConnectionInfo" attribute of the + "VnfInstance" structure by adding unknown entries received in + this attribute. This attribute is not intended for the + modification of VimConnectionInfo entries passed earlier; for + that, the VnfInfoModificationRequest structure shall be used. + This attribute shall only be supported when + - all or part of the granted resources are managed by a VIM and VNF-related + Resource Management in direct mode is applicable. + - all or part of the granted resources are managed by a CISM. + In direct mode, this parameter shall be absent if the VIM or + CISM information was configured to the VNFM in another way, + present otherwise. See note 1. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines the + structure of the "interfaceInfo" and "accessInfo" + attributes, based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values is + expected to change over time as new types or versions of + VIMs become available. The ETSI NFV registry of + VIM-related information provides access to information + about VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The structure of + the registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + cirConnectionInfo: + description: > + Provides information regarding a CIR connection that is + approved to be used by the VNFM to obtain information about OS + container images. It shall be absent in case of rejection or + if the CIR information was configured to the VNFM in another + way or if the granted resources are not managed by a CISM, + present otherwise. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines the + structure of the "interfaceInfo" and "accessInfo" + attributes, based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values is + expected to change over time as new types or versions of + VIMs become available. The ETSI NFV registry of + VIM-related information provides access to information + about VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The structure of + the registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + mciopRepositoryInfo: + description: > + Provides information regarding a MCIOP repository. It shall be + absent in case of rejection or if the MCIOP repository + information was configured to the VNFM in another way or if + the granted resources are not managed by a CISM, present + otherwise. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines the + structure of the "interfaceInfo" and "accessInfo" + attributes, based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values is + expected to change over time as new types or versions of + VIMs become available. The ETSI NFV registry of + VIM-related information provides access to information + about VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The structure of + the registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + zones: + description: > + Identifies resource zones where the resources are approved to + be allocated by the VNFM. + type: array + items: + description: | + This type provides information regarding a resource zone. + type: object + required: + - id + - zoneId + properties: + id: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + zoneGroups: + description: > + Information about groups of resource zones that are related + and that the NFVO has chosen to fulfil a zoneGroup constraint + in the GrantVnfLifecycleOperation request. This information + confirms that the NFVO has honoured the zoneGroup constraints + that were passed as part of "placementConstraints" in the + GrantRequest. + type: array + items: + description: > + This type provides information regarding a resource zone + group. A resource zone group is a group of one or more + related resource zones which can be used in resource + placement constraints. To fulfil such constraint, the NFVO + may decide to place a resource into any zone that belongs to + a particular group. NOTE: A resource zone group can be used + to support overflow from one resource zone into another, in + case a particular deployment supports only non-elastic + resource zones. + type: object + required: + - zoneId + properties: + zoneId: + description: > + References of identifiers of "ZoneInfo" structures, each + of which provides information about a resource zone that + belongs to this group. + type: array + items: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + addResources: + description: > + List of resources that are approved to be added, with one + entry per resource. See note 9. Shall be set when resources + are approved to be added and shall contain the same set of + resources requested to be added in the related GrantRequest. + type: array + items: + description: > + This type contains information about a Compute, storage or + network resource whose addition/update/deletion was granted. + It enables also referencing to a PaaS Service request + definition which has been granted. NOTE: If a + "sharedResource" is provided, the "reservationId" and + "resourceProviderId" shall not be set. + type: object + required: + - resourceDefinitionId + properties: + resourceDefinitionId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + reservationId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + zoneId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + resourceGroupId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + containerNamespace: + description: | + A string defined in IETF RFC 8259. + type: string + mcioConstraints: + description: > + The constraint values to be assigned to MCIOs of a VNF + with containerized components. The key in the key-value + pair indicates the parameter name of the MCIO constraint + in the MCIO declarative descriptor and shall be one of + the possible enumeration values of the + "mcioConstraintsParams" attribute as specified in clause + 7.1.6.2.2 of ETSI GS NFV-IFA 011 [10]. The value in the + keyvalue pair indicates the value to be assigned to the + MCIO constraint. This attribute shall be present if the + granted resources are managed by a CISM. The attribute + shall be absent if the granted resources are not managed + by a CISM. + type: array + items: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + sharedResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + tempResources: + description: > + List of resources that are approved to be temporarily + instantiated during the runtime of the lifecycle operation, + with one entry per resource. See note 9. Shall be set when + resources are approved to be temporarily instantiated and + shall contain the same set of resources requested to be + temporarily instantiated in the related GrantRequest. + type: array + items: + description: > + This type contains information about a Compute, storage or + network resource whose addition/update/deletion was granted. + It enables also referencing to a PaaS Service request + definition which has been granted. NOTE: If a + "sharedResource" is provided, the "reservationId" and + "resourceProviderId" shall not be set. + type: object + required: + - resourceDefinitionId + properties: + resourceDefinitionId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + reservationId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + zoneId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + resourceGroupId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + containerNamespace: + description: | + A string defined in IETF RFC 8259. + type: string + mcioConstraints: + description: > + The constraint values to be assigned to MCIOs of a VNF + with containerized components. The key in the key-value + pair indicates the parameter name of the MCIO constraint + in the MCIO declarative descriptor and shall be one of + the possible enumeration values of the + "mcioConstraintsParams" attribute as specified in clause + 7.1.6.2.2 of ETSI GS NFV-IFA 011 [10]. The value in the + keyvalue pair indicates the value to be assigned to the + MCIO constraint. This attribute shall be present if the + granted resources are managed by a CISM. The attribute + shall be absent if the granted resources are not managed + by a CISM. + type: array + items: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + sharedResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + removeResources: + description: > + List of resources that are approved to be removed, with one + entry per resource. See note 9. Shall be set when resources + are approved to be removed and shall contain the same set of + resources requested to be removed in the related + GrantRequest. + type: array + items: + description: > + This type contains information about a Compute, storage or + network resource whose addition/update/deletion was granted. + It enables also referencing to a PaaS Service request + definition which has been granted. NOTE: If a + "sharedResource" is provided, the "reservationId" and + "resourceProviderId" shall not be set. + type: object + required: + - resourceDefinitionId + properties: + resourceDefinitionId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + reservationId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + zoneId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + resourceGroupId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + containerNamespace: + description: | + A string defined in IETF RFC 8259. + type: string + mcioConstraints: + description: > + The constraint values to be assigned to MCIOs of a VNF + with containerized components. The key in the key-value + pair indicates the parameter name of the MCIO constraint + in the MCIO declarative descriptor and shall be one of + the possible enumeration values of the + "mcioConstraintsParams" attribute as specified in clause + 7.1.6.2.2 of ETSI GS NFV-IFA 011 [10]. The value in the + keyvalue pair indicates the value to be assigned to the + MCIO constraint. This attribute shall be present if the + granted resources are managed by a CISM. The attribute + shall be absent if the granted resources are not managed + by a CISM. + type: array + items: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + sharedResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + updateResources: + description: > + List of resources that are approved to be modified, with one + entry per resource. See note 9. Shall be set when resources + are approved to be updated and shall contain the same set of + resources requested to be updated in the related + GrantRequest. + type: array + items: + description: > + This type contains information about a Compute, storage or + network resource whose addition/update/deletion was granted. + It enables also referencing to a PaaS Service request + definition which has been granted. NOTE: If a + "sharedResource" is provided, the "reservationId" and + "resourceProviderId" shall not be set. + type: object + required: + - resourceDefinitionId + properties: + resourceDefinitionId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + reservationId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + zoneId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + resourceGroupId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + containerNamespace: + description: | + A string defined in IETF RFC 8259. + type: string + mcioConstraints: + description: > + The constraint values to be assigned to MCIOs of a VNF + with containerized components. The key in the key-value + pair indicates the parameter name of the MCIO constraint + in the MCIO declarative descriptor and shall be one of + the possible enumeration values of the + "mcioConstraintsParams" attribute as specified in clause + 7.1.6.2.2 of ETSI GS NFV-IFA 011 [10]. The value in the + keyvalue pair indicates the value to be assigned to the + MCIO constraint. This attribute shall be present if the + granted resources are managed by a CISM. The attribute + shall be absent if the granted resources are not managed + by a CISM. + type: array + items: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + sharedResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + vimAssets: + description: > + Information about assets for the VNF that are defined in VNFD + and managed by the NFVO in the VIM/NFVI, such as software + images and virtualised compute resource flavours. See note 3. + type: object + properties: + computeResourceFlavours: + description: > + Mappings between virtual compute descriptors defined in + the VNFD and compute resource flavours managed in the VIM. + type: array + items: + description: > + If the VIM requires the use of virtual compute resource + flavours during compute resource instantiation, it is + assumed that such flavours are selected or created by + the NFVO based on the information in the virtual compute + descriptor defined in the VNFD. This type defines the + mapping between a virtual compute descriptor in the VNFD + and the corresponding compute resource flavour managed + by the NFVO in the VIM. + type: object + required: + - vnfdVirtualComputeDescId + - vimFlavourId + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfdVirtualComputeDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vimFlavourId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + softwareImages: + description: > + Mappings between software images defined in the VNFD and + software images managed in the VIM. + type: array + items: + description: > + This type contains a mapping between a software image + definition the VNFD and the corresponding software image + managed by the NFVO in the VIM or CIR which is needed + during compute resource instantiation. + + NOTE: For an OS container image, the value of this + attribute is a string concatenating the name and tag of + the + image in the CIR separated by a colon ':' with no spaces, e.g. “dbImage:001”. + type: object + required: + - vnfdSoftwareImageId + - vimSoftwareImageId + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfdSoftwareImageId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vimSoftwareImageId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + snapshotResources: + description: > + Mappings between snapshot resources defined in the VNF + snapshot package and resources managed in the VIM. + type: array + items: + description: > + This type contains a mapping between a snapshot resource + definition related to a VNF snapshot and the + corresponding resource managed by the NFVO in the VIM + which is needed during the revert to VNF snapshot + operation. + type: object + required: + - vnfSnapshotId + - vnfcSnapshotId + - vimSnapshotResourceId + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfSnapshotId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfcSnapshotId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + storageSnapshotId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vimSnapshotResourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + storageAssets: + description: > + Mappings between virtual storages defined in the VNFD and + virtual storages managed in the NFVI. + type: array + items: + description: > + This type provides a mapping between a + VirtualStorageDesc in the VNFD and the corresponding + virtual storage managed by the NFVO in the NFVI. + type: object + required: + - virtualStorageDescId + - storageClassName + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + storageClassName: + description: | + A string defined in IETF RFC 8259. + type: string + paasAssets: + description: > + Information about PaaS Services assigned to the VNF and that + are managed in the PSM by the NFVO. + type: array + items: + type: object + required: + - paasServiceType + - paasServiceId + - paasServiceRequestId + - paasServiceHandle + properties: + paasServiceType: + description: | + A string defined in IETF RFC 8259. + type: string + paasServiceId: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceVersion: + description: | + A version. + type: string + paasServiceRequestId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + PaasServiceHandle: + description: > + This type provides information enabling the access and + use of the PaaS Service by the VNF instance. The type + and format of the handle depends on the form that the + PaaS Service is formed. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + extVirtualLinks: + description: > + Information about external VLs to connect the VNF to. See + notes 5, 7 and 8. If this attribute is present according to + note 5 or note 7, it need not contain those entries that are + unchanged compared to the entries that were passed in the LCM + operation which is related to this granting exchange. + type: array + items: + description: "This type represents an external VL.\n* NOTE 1:\tA link port is not needed for an external CP instance that exposes a CP in the following cases:\n 1) For a VIP CP directly exposed as an external CP:\n 1.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD.\n 1.2) A dedicated IP address is allocated as VIP address, but the NFVO indicates that no port is needed\n (createExtLinkPort in VnfExtCpConfig set to false).\n 2) For a VIP CP exposed as an external CP via a floating IP address:\n 2.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD, and the VNFC CP\n associated to the VIP CP is also exposed via a floating IP address.\n 3) For a VIRTUAL CP exposed as an external CP.\n 4) For a VNFC CP exposed as an external CP in a secondary container cluster external network or a\n secondary container cluster internal network.\n\n* NOTE 2: An example of the network attachment definition resource when the container infrastructure service\n management is a Kubernetes® instance is a network attachment definition (NAD).\n* NOTE 3: Either \"extCps\" or “extCpsDeletion\" shall be present, but not both.\n" + type: object + required: + - id + - resourceId + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + extCps: + description: > + External CPs of the VNF to be connected to this external + VL. Entries in the list of external CP data that are + unchanged need not be supplied if the ExtVirtualLinkData + structure is part of a request or response that modifies + the external connectivity. See note 3. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. + + The entries shall be applied by the VNFM according + to the rules of JSON Merge Patch (see IETF RFC + 7396). See notes 2, 3, 4, 5, 6. In case of + deleting an external CP, the list of instances to + be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extLinkPorts: + description: > + Externally provided link ports to be used to connect + external connection points to this external VL. If this + attribute is not present, the VNFM shall create the link + ports on the external VL except in the cases defined + below. See note 1. + type: array + items: + description: "This type represents an externally provided link port to be used to connect an external connection point to an external VL. * NOTE:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + extNetAttDefResourceData: + description: > + Externally provided network attachment definition + resource(s) that provide the specification of the + interface to attach external CPs to this external VL. + See note 2. It is only applicable if the external VL is + realized by a secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + This type represents a network attachment definition + resource that provides the specification of the + interface to be used to connect one or multiple + connection points to a secondary container cluster + network realizing a VL. + type: object + required: + - netAttDefResourceId + - resourceHandle + properties: + netAttDefResourceId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + extCpsDeletion: + description: > + External CPs of the VNF to be disconnected from this + external VL and to be deleted. See note 3. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. + + The entries shall be applied by the VNFM according + to the rules of JSON Merge Patch (see IETF RFC + 7396). See notes 2, 3, 4, 5, 6. In case of + deleting an external CP, the list of instances to + be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extManagedVirtualLinks: + description: > + Information about internal VLs that are managed by other + entities than the VNFM. See notes 4, 5, 7 and 8. + type: array + items: + description: > + This type represents an externally-managed internal VL. + + * NOTE 1: It is only applicable if the externally-managed VL + is realized by a secondary container cluster network. It + shall + not be present otherwise. + * NOTE 2: A link port is not needed for a VNFC internal + connection point connected to a secondary container cluster + network. + * NOTE 3: An example of the network attachment definition + resource when the container infrastructure service + management is a Kubernetes® instance is a network attachment definition (NAD). + + * NOTE 4: In the case that the cloud native template + included in the MCIOP describes the set of VNFC instances, + an + instance of intCp need not be included for each VNFC instance as all instances would contain the same + information. It is sufficient to include one intCp for the related CPD. The case of using, for a scalable VDU, a + cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present + document version + * NOTE 5: Both "vnfLinkPort" and "netAttDefResource" + attributes can be provided in a "ExtManagedVirtualLinkData" + to indicate + that a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs + type: object + required: + - id + - vnfVirtualLinkDescId + - resourceId + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfVirtualLinkDescId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + netAttDefResourceData: + description: > + Externally provided network attachment definition + resource(s) that provide the specification of the + interface to attach VNFC connection points to this + externallymanaged VL. See notes 1, 3 and 5. + type: array + items: + description: > + This type represents a network attachment definition + resource that provides the specification of the + interface to be used to connect one or multiple + connection points to a secondary container cluster + network realizing a VL. + type: object + required: + - netAttDefResourceId + - resourceHandle + properties: + netAttDefResourceId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + intCp: + description: > + Internal CPs of the VNF to be connected to this + externally-managed VL. See note 1 and 4. + type: array + items: + description: > + This type represents input information related to one + or more VNF internal CP instances created based on the + same CPD. + + NOTE: Cardinality greater than 1 is only applicable + for specific cases where more than one network + attachment + definition resource is needed to fulfil the connectivity requirements of the VNF internal CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall + belong to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + type: object + required: + - cpdId + - netAttDefResourceId + properties: + cpdId: + description: > + An identifier with the intention of being globally + unique. + type: string + netAttDefResourceId: + description: > + Identifiers of the “NetAttDefResourceData” + structure that provides the specification of the + interface to attach the VNF internal CP created + from the CPD identified by cpdId to a secondary + container cluster network. See note. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfLinkPort: + description: > + Externally provided link ports to be used to connect + VNFC connection points to this externally-managed VL on + this network resource. If this attribute is not present, + the VNFM shall create the link ports on the + externally-managed VL. See notes 2 and 5. + type: array + items: + description: > + This type represents an externally provided link port + to be used to connect a VNFC connection point to an + externally managed VL. + type: object + required: + - vnfLinkPortId + - resourceHandle + properties: + vnfLinkPortId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + extManagedMultisiteVirtualLinkId: + description: > + An identifier with the intention of being globally + unique. + type: string + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + - vnfLcmOpOcc + - vnfInstance + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfLcmOpOcc: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + Grants.Post.202: + description: > + 202 ACCEPTED + + + Shall be returned when the request has been accepted for processing + + and it is expected to take some time to create the grant (asynchronous + mode). + + The response body shall be empty. + + The HTTP response shall include a "Location" HTTP header that indicates + the URI + + of the "Individual grant" resource that will be created once the + granting decision has been made. + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Grants.Post.403: + description: | + 403 FORBIDDEN + + Shall be returned upon the following error: The grant + has been rejected. + A ProblemDetails structure shall be included in the + response to provide more details about the rejection + in the "details" attribute. + headers: + Location: + description: | + The resource URI of the created subscription resource. + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualGrant.Get.200: + description: > + 200 OK + + + Shall be returned when the grant has been read successfully. + + A representation of the "Individual grant" resource shall be returned in + the response body. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: "This type represents a grant.\nNOTE 1: This interface allows to signal the use of multiple VIMs per VNF. The specification\n for managing the VNF internal VL requirements across multiple VIMs is supported via\n \"externally-managed internal VLs\" and \"multi-site connectivity services\".\nNOTE 2: Void. NOTE 3: The Grant response allows the NFVO to pass to the VNFM VIM assets related to the VNF \n package that is identified in the corresponding Grant request. Because only the operations\n InstantiateVnf, ChangeCurrentVnfPkg and the update of the vnfdId by PATCH can imply changes\n in the set of VIM assets, the NFVO shall not change this set in any other case. To signal the\n set of VIM assets, the following applies:\n a)\tIf the current LCM operation is InstantiateVnf, the NFVO shall send in the Grant response\n the full set of VIM assets related to the VNF package defined by the vnfdId in the related\n Grant request.\n b)\tIf the current LCM operation is ChangeCurrentVnfPkg, the NFVO shall send in the\n Grant response the full set of VIM assets related to the VNF package defined by the destVnfdId\n in the related Grant request.\n c)\tFor any other operation: If the set of VIM assets has changed since the end of the previous\n granted operation because a PATCH operation has changed the vnfdId between the previous granted\n operation and the operation to which the current granting exchange relates, the NFVO shall send\n in the Grant response the full set of VIM assets related to the VNF package defined by the vnfdId\n in the related Grant request. Otherwise, the NFVO shall either send in the Grant response the full\n set of VIM assets related to the VNF package defined by the vnfdId in the related Grant request, or\n shall not send any VIM assets at all.\n During each LCM operation occurrence other than a \"ChangeCurrentVnfPkg\" operation,\n the VIM assets that relate to the VNF package identified by the current value of\n the vnfdId attribute in the \"VnfInstance\" structure shall be used by the\n VNFM for newly created resources and updated resources.\nNOTE 4: The indication of externally-managed internal VLs is needed in case networks have been\n pre-configured for use with certain VNFs, for instance to ensure that these networks have\n certain properties such as security or acceleration features, or to address particular network\n topologies (e.g., multi-site connectivity). The present document assumes that externally-managed\n internal VLs are managed by the NFVO and created towards the VIM and WIM.\nNOTE 5: For any VNF lifecycle management operation request that allows to pass \"extVirtualLinks\" and/or\n \"extManagedVirtualLinks\" parameters, such as InstantiateVnf, ChangeVnfFlavour, ChangeExtVnfConnectivity or\n ChangeCurrentVnfPackage, the NFVO may provide the \"extVirtualLinks\" and/or \"extManagedVirtualLinks\" attributes\n in the Grant to override the values passed in these parameters previously in the associated VNF lifecycle\n management request, if the lifecycle management request has originated from the NFVO itself. The NFVO shall\n not provide the \"extVirtualLinks\" and/or \"extManagedVirtualLinks\" attributes in the Grant in case the LCM\n request did not originate from the NFVO itself or the granted LCM operation request does not allow to pass\n these parameters.\nNOTE 6: The NFVO shall set the value of the attribute by copying the value from the associated \n GrantRequest.\nNOTE 7: In case of granting an InstantiateVnf request that has originated from the NFVO and that \n did not contain the \"extVirtualLinks\" attribute, this attribute shall be set by the NFVO. \n Further in case of granting an InstantiateVnf request that has originated from the NFVO \n and that did not contain the \"extManagedVirtualLinks\" attribute, this attribute shall be \n set by the NFVO if there is the need to provide information about externally-managed virtual \n links.\nNOTE 8: The resulting \"extVirtualLinks\" or \"extManagedVirtualLinks\" information is calculated as follows: \n In a first step, the information passed in the related LCM operation is applied to the baseline\n information known from earlier LCM operation executions. In a second step, the information passed\n in the Grant is applied to the information resulting from the first step.\nNOTE 9: For resources related to ResourceDefinition whose VDU has the attribute \n isNumOfInstancesClusterBased set to TRUE, only one occurrence of the addResources, or \n tempResources or removeResources, or updateResources shall be included.\n" + type: object + required: + - id + - vnfInstanceId + - vnfLcmOpOccId + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfLcmOpOccId: + description: | + An identifier with the intention of being globally unique. + type: string + vimConnectionInfo: + description: > + Provides information regarding VIM and/or CISM connections + that are approved to be used by the VNFM to allocate resources + and provides parameters of these VIM and/or CISM connections. + The VNFM shall update the "vimConnectionInfo" attribute of the + "VnfInstance" structure by adding unknown entries received in + this attribute. This attribute is not intended for the + modification of VimConnectionInfo entries passed earlier; for + that, the VnfInfoModificationRequest structure shall be used. + This attribute shall only be supported when + - all or part of the granted resources are managed by a VIM and VNF-related + Resource Management in direct mode is applicable. + - all or part of the granted resources are managed by a CISM. + In direct mode, this parameter shall be absent if the VIM or + CISM information was configured to the VNFM in another way, + present otherwise. See note 1. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines the + structure of the "interfaceInfo" and "accessInfo" + attributes, based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values is + expected to change over time as new types or versions of + VIMs become available. The ETSI NFV registry of + VIM-related information provides access to information + about VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The structure of + the registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + cirConnectionInfo: + description: > + Provides information regarding a CIR connection that is + approved to be used by the VNFM to obtain information about OS + container images. It shall be absent in case of rejection or + if the CIR information was configured to the VNFM in another + way or if the granted resources are not managed by a CISM, + present otherwise. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines the + structure of the "interfaceInfo" and "accessInfo" + attributes, based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values is + expected to change over time as new types or versions of + VIMs become available. The ETSI NFV registry of + VIM-related information provides access to information + about VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The structure of + the registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + mciopRepositoryInfo: + description: > + Provides information regarding a MCIOP repository. It shall be + absent in case of rejection or if the MCIOP repository + information was configured to the VNFM in another way or if + the granted resources are not managed by a CISM, present + otherwise. + type: object + additionalProperties: + description: "This type represents parameters to connect to a VIM, a CISM, a CIR or a MCIOP repository for managing the resources of a VNF instance.\nThis structure is used to convey VIM-related, CISM-related, CIR-related, or MCIOP-repository-related parameters over the Or-Vnfm interface. Additional parameters for a VIM, a CISM, a CIR or a MCIOP repository may be configured into the VNFM by means outside the scope of the present document and bound to the identifier of that VIM.\n* NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM, CISM, CIR or MCIOP repository is provided\n through a secure connection over HTTP Secure (HTTP over SSL/TLS), and the connection might also be\n established through a VPN (for example TLS-based VPN tunnelling) for site-to-site connection, the\n \"accessInfo\" JSON data structure, and the sensitive data related information (\"username\"/\"password\" as\n required properties for authentication purpose), will be transmitted as plain text through a TLS tunnel\n without additional encoding/encryption before transmitting it, making the sensitive data visible to the\n endpoint. The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM, CISM, CIR or MCIOP repository.\n* NOTE 3: ETSI GS NFV-SOL 009 specifies the means to configure into the VNFM applicable VIM connection\n information via the \"NFV-MANO Configuration and Information Management\" interface.\n* NOTE 4: Due to the possibility of configuring such information into the VNFM out-of-band, by means outside the scope of\n the present document, as well as in-band, by means specified in the present document, care should be taken to\n avoid unintended conflicts in the VNFM when managing such information.\n" + type: object + required: + - vimType + properties: + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimType: + description: > + Discriminator for the different types of the VIM + information. The value of this attribute determines the + structure of the "interfaceInfo" and "accessInfo" + attributes, based on the type of the VIM., CISM, CIR or + MCIOP repository. The set of permitted values is + expected to change over time as new types or versions of + VIMs become available. The ETSI NFV registry of + VIM-related information provides access to information + about VimConnectionInfo definitions for various VIM, + CISM, CIR or MCIOP repository types. The structure of + the registry is defined in annex C. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + zones: + description: > + Identifies resource zones where the resources are approved to + be allocated by the VNFM. + type: array + items: + description: | + This type provides information regarding a resource zone. + type: object + required: + - id + - zoneId + properties: + id: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + zoneId: + description: > + An identifier with the intention of being globally + unique. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + zoneGroups: + description: > + Information about groups of resource zones that are related + and that the NFVO has chosen to fulfil a zoneGroup constraint + in the GrantVnfLifecycleOperation request. This information + confirms that the NFVO has honoured the zoneGroup constraints + that were passed as part of "placementConstraints" in the + GrantRequest. + type: array + items: + description: > + This type provides information regarding a resource zone + group. A resource zone group is a group of one or more + related resource zones which can be used in resource + placement constraints. To fulfil such constraint, the NFVO + may decide to place a resource into any zone that belongs to + a particular group. NOTE: A resource zone group can be used + to support overflow from one resource zone into another, in + case a particular deployment supports only non-elastic + resource zones. + type: object + required: + - zoneId + properties: + zoneId: + description: > + References of identifiers of "ZoneInfo" structures, each + of which provides information about a resource zone that + belongs to this group. + type: array + items: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + addResources: + description: > + List of resources that are approved to be added, with one + entry per resource. See note 9. Shall be set when resources + are approved to be added and shall contain the same set of + resources requested to be added in the related GrantRequest. + type: array + items: + description: > + This type contains information about a Compute, storage or + network resource whose addition/update/deletion was granted. + It enables also referencing to a PaaS Service request + definition which has been granted. NOTE: If a + "sharedResource" is provided, the "reservationId" and + "resourceProviderId" shall not be set. + type: object + required: + - resourceDefinitionId + properties: + resourceDefinitionId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + reservationId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + zoneId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + resourceGroupId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + containerNamespace: + description: | + A string defined in IETF RFC 8259. + type: string + mcioConstraints: + description: > + The constraint values to be assigned to MCIOs of a VNF + with containerized components. The key in the key-value + pair indicates the parameter name of the MCIO constraint + in the MCIO declarative descriptor and shall be one of + the possible enumeration values of the + "mcioConstraintsParams" attribute as specified in clause + 7.1.6.2.2 of ETSI GS NFV-IFA 011 [10]. The value in the + keyvalue pair indicates the value to be assigned to the + MCIO constraint. This attribute shall be present if the + granted resources are managed by a CISM. The attribute + shall be absent if the granted resources are not managed + by a CISM. + type: array + items: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + sharedResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + tempResources: + description: > + List of resources that are approved to be temporarily + instantiated during the runtime of the lifecycle operation, + with one entry per resource. See note 9. Shall be set when + resources are approved to be temporarily instantiated and + shall contain the same set of resources requested to be + temporarily instantiated in the related GrantRequest. + type: array + items: + description: > + This type contains information about a Compute, storage or + network resource whose addition/update/deletion was granted. + It enables also referencing to a PaaS Service request + definition which has been granted. NOTE: If a + "sharedResource" is provided, the "reservationId" and + "resourceProviderId" shall not be set. + type: object + required: + - resourceDefinitionId + properties: + resourceDefinitionId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + reservationId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + zoneId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + resourceGroupId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + containerNamespace: + description: | + A string defined in IETF RFC 8259. + type: string + mcioConstraints: + description: > + The constraint values to be assigned to MCIOs of a VNF + with containerized components. The key in the key-value + pair indicates the parameter name of the MCIO constraint + in the MCIO declarative descriptor and shall be one of + the possible enumeration values of the + "mcioConstraintsParams" attribute as specified in clause + 7.1.6.2.2 of ETSI GS NFV-IFA 011 [10]. The value in the + keyvalue pair indicates the value to be assigned to the + MCIO constraint. This attribute shall be present if the + granted resources are managed by a CISM. The attribute + shall be absent if the granted resources are not managed + by a CISM. + type: array + items: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + sharedResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + removeResources: + description: > + List of resources that are approved to be removed, with one + entry per resource. See note 9. Shall be set when resources + are approved to be removed and shall contain the same set of + resources requested to be removed in the related + GrantRequest. + type: array + items: + description: > + This type contains information about a Compute, storage or + network resource whose addition/update/deletion was granted. + It enables also referencing to a PaaS Service request + definition which has been granted. NOTE: If a + "sharedResource" is provided, the "reservationId" and + "resourceProviderId" shall not be set. + type: object + required: + - resourceDefinitionId + properties: + resourceDefinitionId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + reservationId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + zoneId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + resourceGroupId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + containerNamespace: + description: | + A string defined in IETF RFC 8259. + type: string + mcioConstraints: + description: > + The constraint values to be assigned to MCIOs of a VNF + with containerized components. The key in the key-value + pair indicates the parameter name of the MCIO constraint + in the MCIO declarative descriptor and shall be one of + the possible enumeration values of the + "mcioConstraintsParams" attribute as specified in clause + 7.1.6.2.2 of ETSI GS NFV-IFA 011 [10]. The value in the + keyvalue pair indicates the value to be assigned to the + MCIO constraint. This attribute shall be present if the + granted resources are managed by a CISM. The attribute + shall be absent if the granted resources are not managed + by a CISM. + type: array + items: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + sharedResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + updateResources: + description: > + List of resources that are approved to be modified, with one + entry per resource. See note 9. Shall be set when resources + are approved to be updated and shall contain the same set of + resources requested to be updated in the related + GrantRequest. + type: array + items: + description: > + This type contains information about a Compute, storage or + network resource whose addition/update/deletion was granted. + It enables also referencing to a PaaS Service request + definition which has been granted. NOTE: If a + "sharedResource" is provided, the "reservationId" and + "resourceProviderId" shall not be set. + type: object + required: + - resourceDefinitionId + properties: + resourceDefinitionId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + reservationId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + zoneId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + resourceGroupId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + containerNamespace: + description: | + A string defined in IETF RFC 8259. + type: string + mcioConstraints: + description: > + The constraint values to be assigned to MCIOs of a VNF + with containerized components. The key in the key-value + pair indicates the parameter name of the MCIO constraint + in the MCIO declarative descriptor and shall be one of + the possible enumeration values of the + "mcioConstraintsParams" attribute as specified in clause + 7.1.6.2.2 of ETSI GS NFV-IFA 011 [10]. The value in the + keyvalue pair indicates the value to be assigned to the + MCIO constraint. This attribute shall be present if the + granted resources are managed by a CISM. The attribute + shall be absent if the granted resources are not managed + by a CISM. + type: array + items: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + sharedResource: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by a VNF + instance. Information about the resource is available + from the VIM. + + * NOTE 1: The value set of the "vimLevelResourceType" + attribute is within the scope of the VIM or CISM or the + resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure service + management is a Kubernetes® instance the resourceId + shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM or the + CISM or the resource provider. See note 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource information + which resource and resource type specific, and which + is available from the VIM or the CISM or the + resource provider. + + * NOTE: At least one attribute shall be present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the storage + resource is bound. It may be present for storage + resources in the scope of the CISM and shall be + absent otherwise. See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with + the provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided + to illustrate that the values associated with + different keys can be of different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. This + attribute shall be present if the resource is + managed by a CISM and it shall be absent otherwise. + type: string + vimAssets: + description: > + Information about assets for the VNF that are defined in VNFD + and managed by the NFVO in the VIM/NFVI, such as software + images and virtualised compute resource flavours. See note 3. + type: object + properties: + computeResourceFlavours: + description: > + Mappings between virtual compute descriptors defined in + the VNFD and compute resource flavours managed in the VIM. + type: array + items: + description: > + If the VIM requires the use of virtual compute resource + flavours during compute resource instantiation, it is + assumed that such flavours are selected or created by + the NFVO based on the information in the virtual compute + descriptor defined in the VNFD. This type defines the + mapping between a virtual compute descriptor in the VNFD + and the corresponding compute resource flavour managed + by the NFVO in the VIM. + type: object + required: + - vnfdVirtualComputeDescId + - vimFlavourId + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfdVirtualComputeDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vimFlavourId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + softwareImages: + description: > + Mappings between software images defined in the VNFD and + software images managed in the VIM. + type: array + items: + description: > + This type contains a mapping between a software image + definition the VNFD and the corresponding software image + managed by the NFVO in the VIM or CIR which is needed + during compute resource instantiation. + + NOTE: For an OS container image, the value of this + attribute is a string concatenating the name and tag of + the + image in the CIR separated by a colon ':' with no spaces, e.g. “dbImage:001”. + type: object + required: + - vnfdSoftwareImageId + - vimSoftwareImageId + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfdSoftwareImageId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + vimSoftwareImageId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + snapshotResources: + description: > + Mappings between snapshot resources defined in the VNF + snapshot package and resources managed in the VIM. + type: array + items: + description: > + This type contains a mapping between a snapshot resource + definition related to a VNF snapshot and the + corresponding resource managed by the NFVO in the VIM + which is needed during the revert to VNF snapshot + operation. + type: object + required: + - vnfSnapshotId + - vnfcSnapshotId + - vimSnapshotResourceId + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfSnapshotId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfcSnapshotId: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + storageSnapshotId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally + unique. + type: string + vimSnapshotResourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + storageAssets: + description: > + Mappings between virtual storages defined in the VNFD and + virtual storages managed in the NFVI. + type: array + items: + description: > + This type provides a mapping between a + VirtualStorageDesc in the VNFD and the corresponding + virtual storage managed by the NFVO in the NFVI. + type: object + required: + - virtualStorageDescId + - storageClassName + properties: + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + virtualStorageDescId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + storageClassName: + description: | + A string defined in IETF RFC 8259. + type: string + paasAssets: + description: > + Information about PaaS Services assigned to the VNF and that + are managed in the PSM by the NFVO. + type: array + items: + type: object + required: + - paasServiceType + - paasServiceId + - paasServiceRequestId + - paasServiceHandle + properties: + paasServiceType: + description: | + A string defined in IETF RFC 8259. + type: string + paasServiceId: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceVersion: + description: | + A version. + type: string + paasServiceRequestId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + PaasServiceHandle: + description: > + This type provides information enabling the access and + use of the PaaS Service by the VNF instance. The type + and format of the handle depends on the form that the + PaaS Service is formed. + type: object + required: + - id + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + extra: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. + In JSON, a set of keyvalue pairs is represented as + an object. It shall comply with the provisions + defined in clause 4 of IETF RFC 8259. In the + following example, a list of key-value pairs with + four keys ("aString", "aNumber", "anArray" and + "anObject") is provided to illustrate that the + values associated with different keys can be of + different type. + type: object + extVirtualLinks: + description: > + Information about external VLs to connect the VNF to. See + notes 5, 7 and 8. If this attribute is present according to + note 5 or note 7, it need not contain those entries that are + unchanged compared to the entries that were passed in the LCM + operation which is related to this granting exchange. + type: array + items: + description: "This type represents an external VL.\n* NOTE 1:\tA link port is not needed for an external CP instance that exposes a CP in the following cases:\n 1) For a VIP CP directly exposed as an external CP:\n 1.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD.\n 1.2) A dedicated IP address is allocated as VIP address, but the NFVO indicates that no port is needed\n (createExtLinkPort in VnfExtCpConfig set to false).\n 2) For a VIP CP exposed as an external CP via a floating IP address:\n 2.1) No dedicated IP address is allocated as VIP address, as indicated in the VNFD, and the VNFC CP\n associated to the VIP CP is also exposed via a floating IP address.\n 3) For a VIRTUAL CP exposed as an external CP.\n 4) For a VNFC CP exposed as an external CP in a secondary container cluster external network or a\n secondary container cluster internal network.\n\n* NOTE 2: An example of the network attachment definition resource when the container infrastructure service\n management is a Kubernetes® instance is a network attachment definition (NAD).\n* NOTE 3: Either \"extCps\" or “extCpsDeletion\" shall be present, but not both.\n" + type: object + required: + - id + - resourceId + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + extCps: + description: > + External CPs of the VNF to be connected to this external + VL. Entries in the list of external CP data that are + unchanged need not be supplied if the ExtVirtualLinkData + structure is part of a request or response that modifies + the external connectivity. See note 3. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. + + The entries shall be applied by the VNFM according + to the rules of JSON Merge Patch (see IETF RFC + 7396). See notes 2, 3, 4, 5, 6. In case of + deleting an external CP, the list of instances to + be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extLinkPorts: + description: > + Externally provided link ports to be used to connect + external connection points to this external VL. If this + attribute is not present, the VNFM shall create the link + ports on the external VL except in the cases defined + below. See note 1. + type: array + items: + description: "This type represents an externally provided link port to be used to connect an external connection point to an external VL. * NOTE:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" + type: object + required: + - id + - resourceHandle + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + trunkResourceId: + description: > + An identifier maintained by the VIM or the CISM + or other resource provider. It is expected to be + unique within the VIM instance. + type: string + extNetAttDefResourceData: + description: > + Externally provided network attachment definition + resource(s) that provide the specification of the + interface to attach external CPs to this external VL. + See note 2. It is only applicable if the external VL is + realized by a secondary container cluster network. It + shall not be present otherwise. + type: array + items: + description: > + This type represents a network attachment definition + resource that provides the specification of the + interface to be used to connect one or multiple + connection points to a secondary container cluster + network realizing a VL. + type: object + required: + - netAttDefResourceId + - resourceHandle + properties: + netAttDefResourceId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + extCpsDeletion: + description: > + External CPs of the VNF to be disconnected from this + external VL and to be deleted. See note 3. + type: array + items: + description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or\n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a cpConfig\n map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or\n \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related\n \"cpConfig\" map entries to a new \"extCpData\" structure.\n* NOTE 5: Subports need not be used for containerized VNFCs. The application container can send and receive IP \n packets with any VLAN tag as long as the network interface to connect to the secondary container cluster \n network has been configured appropriately. Thus, no individual cpConfig, except the one representing the \n trunk, need be modelled to allow traffic tagged with a particular VLAN through the connection point.\n* NOTE 6: In the case that the cloud native template included in the MCIOP describes the set of VNFC instances, for \n containerized VNFCs individual connection points need not be configured for each VNFC instance. It is only \n required to configure one cpConfig per cpdId, not per VNFC instance. The case of using, for a scalable VDU, a \n cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present \n document version.\n" + type: object + required: + - cpdId + - cpConfig + properties: + cpdId: + description: > + An identifier that is unique within a VNF + descriptor. + type: string + cpConfig: + description: > + Map of instance data that need to be configured on + the CP instances created from the respective CPD. + + The key of the map which identifies the individual + VnfExtCpConfig entries is of type + "IdentifierInVnf" and is managed by the NFVO. + + The entries shall be applied by the VNFM according + to the rules of JSON Merge Patch (see IETF RFC + 7396). See notes 2, 3, 4, 5, 6. In case of + deleting an external CP, the list of instances to + be deleted. + type: object + additionalProperties: + description: > + This type represents an externally provided link + port, or a network attachment definition + resource of secondary container cluster network, + or network address information per instance of + an external connection point. In the case of + VM-based deployment of the VNFC exposing the + external CP: + 1. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the + external VL. + 2. In case a link port is not provided, the VNFM shall create a link port on the external VL and use that link port + to connect the external CP to the external VL. + In the case of container-based deployment of the + VNFC exposing the external CP, the VNFM shall + use the network attachment definition resource + of secondary container cluster network when + connecting the CP to the external VL. + + * NOTE 1: The following conditions apply to the + attributes "linkPortId" and "cpProtocolData" for + an external CP + instance connected or to be connected to a virtual network not categorized as secondary container cluster network: + 1) Void. + 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance + representing a subport that is to be created, or an external CP instance that is to be created by creating the + corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing + external CP instance that is to be re-configured or added to a particular external virtual link. + 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. + 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a + precreated link port, and the VNFM can use means outside the scope of the present document to obtain the + pre-configured address information for the connection point from the resource representing the link port. + 5) If both "cpProtocolData" and "linkportId" are provided, the NFVO shall ensure that the + cpProtocolData can be used with the pre-created link port referenced by "linkPortId". + + * NOTE 2: The following conditions apply to the + attributes “netAttDefResourceId” and + “cpProtocolData” for an external CP + instance connected or to be connected to a secondary container cluster network: + 1) Void. + 2) The "netAttDefResourceId" attribute shall be present and the "cpProtocolData" attribute may be present for + a to-be-created external CP instance or an existing external CP instance. + * NOTE 3: Cardinality greater than 1 is only + applicable for specific cases where more than + one network attachment + definition resource is needed to fulfil the connectivity requirements of the external CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall belong + to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" a attribute in the + "NetAttDefResourceData". + * NOTE 4: Either linkPortId or + netAttDefResourceId may be included, but not + both. + anyOf: + - required: + - linkPortId + - required: + - cpProtocolData + - required: + - netAttDefResourceId + type: object + properties: + parentCpConfigId: + description: > + An identifier that is unique for the + respective type within a VNF instance, but + may not be globally unique. + type: string + linkPortId: + description: > + An identifier with the intention of being + globally unique. + type: string + createExtLinkPort: + description: > + Indicates to the VNFM the need to create a + dedicated link port for the external CP. If + set to True, the VNFM shall create a link + port. If set to False, the VNFM shall not + create a link port. This attribute is only + applicable for external CP instances without + a floating IP address that expose a VIP CP + instance for which a dedicated IP address is + allocated. It shall be present in that case + and shall be absent otherwise. + type: boolean + netAttDefResourceId: + description: > + Identifier of the “NetAttDefResourceData” + structure that provides the specification of + the interface to attach the external CP to a + secondary container cluster network. It is + only applicable if the external CP is + connected or to be connected to a secondary + container cluster network. It shall not be + present if the external CP is related to a + virtual network not categorized as secondary + container cluster network. See notes 2, 3 + and 4. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + cpProtocolData: + description: > + Parameters for configuring the network + protocols on the link port that connects the + CP to a VL and the domain names for the + external CP. See notes 1 and 2. + type: array + items: + description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" + type: object + required: + - layerProtocol + properties: + layerProtocol: + description: > + Identifier of layer(s) and protocol(s). + Permitted values: + - IP_OVER_ETHERNET. + - IP_FOR_VIRTUAL_CP + See note + type: string + enum: + - IP_OVER_ETHERNET + - IP_FOR_VIRTUAL_CP + ipOverEthernet: + description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI's transport technology.\n" + type: object + anyOf: + - required: + - macAddress + - required: + - ipAddresses + 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 + segmentationType: + description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values:\n -\tVLAN: the subport uses VLAN as encapsulation type.\n -\tINHERIT: the subport gets its segmentation type from the network it's connected to.\nThis attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" + type: string + enum: + - VLAN + - INHERIT + segmentationId: + description: > + Identification of the network segment to + which the CP instance connects to. See + note 3 and note 4. + type: string + ipAddresses: + description: > + List of IP addresses to assign to the CP + instance. Each entry represents IP + address data for fixed or dynamic IP + address assignment per subnet. If this + attribute is not present, no IP address + shall be assigned. See note 1. + type: array + items: + type: object + required: + - type + oneOf: + - required: + - fixedAddresses + - required: + - numDynamicAddresses + - required: + - addressRange + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + fixedAddresses: + description: > + Fixed addresses to assign (from the + subnet defined by "subnetId" if + provided). See note 2. + type: array + items: + 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 + numDynamicAddresses: + description: > + Number of dynamic addresses to assign + (from the subnet defined by "subnetId" + if provided). See note 2. + type: integer + addressRange: + description: > + An IP address range to be used, e.g. in + case of egress connections. In case this + attribute is present, IP addresses from + the range will be used. See note 2. + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + subnetId: + description: > + An identifier maintained by the VIM or + the CISM or other resource provider. It + is expected to be unique within the VIM + instance. + type: string + virtualCpAddress: + description: > + This type represents network address + data for a virtual CP. + + * NOTE 1: The loadBalancerIp and the + loadBalancerSourceRanges attributes are + only used if the CIS cluster is set up + to be + able to configure an external load balancer. Otherwise it shall be ignored. + * NOTE 2: In case the cluster can + configure an external load balancer but + no loadBalancerIp is provided the + container + cluster will assign an IP address. + * NOTE 3: The attribute is only relevant + if the virtual CP is instantiated in a + cluster that supports configuration of + IP + address pools for virtual CPs. Otherwise it shall be ignored. MetalLB is an example of a solution for + Kubernetes® that supports configuration of address pools for load balancer services. + * NOTE 4: The loadBalancerIp, + addressPoolName and the externalIp + attributes shall not be present at the + same time. + type: object + required: + - type + properties: + type: + description: > + The type of the IP addresses. Permitted + values: IPV4, IPV6. + type: string + enum: + - IPV4 + - IPV6 + loadBalancerIp: + 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 + externalIp: + 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 + addressPoolName: + description: > + Name of an address pool from which the + CIS cluster will assign an IP address to + the virtual CP. See notes 3 and 4. + type: string + loadBalancerSourceRanges: + description: > + List of client IP address ranges allowed + to access an external load balancer. See + note 1. + type: array + items: + type: object + required: + - minAddress + - maxAddress + properties: + minAddress: + 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 + maxAddress: + 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 + fullyQualifiedDomainNames: + description: > + Specifies the fully qualified domain + names (FQDN) to apply to the CP. + type: array + items: + type: string + relativeDomainNames: + description: > + Specifies values of relative domain + names to be considered when setting the + fully qualified domain names. + type: array + items: + type: string + cpSecurityGroupData: + description: > + This type provides input parameters for + modifying and overriding security groups. + The parameters identify which + "SecurityGroupRule" specified in the VNFD is + activated/deactivated and for an activated + security group rule the values of attributes + defined in the VNFD that can be overriden + such as "portRangeMin" and "portRangeMax". + type: object + required: + - securityGroupRuleId + properties: + securityGroupRuleId: + description: > + An identifier that is unique within a + VNF descriptor. + type: string + isActivated: + description: > + Indicates whether the rule is to be + active (true) or inactive (false). If no + attribute value is provided, the + Security Group Rule is activated by + default. + type: boolean + portRangeMin: + description: > + Value for the minimum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + portRangeMax: + description: > + Value for the maximum port number in the + range that is matched by the security + group rule. The value shall be within + the range "0 - 65535". + type: integer + extManagedVirtualLinks: + description: > + Information about internal VLs that are managed by other + entities than the VNFM. See notes 4, 5, 7 and 8. + type: array + items: + description: > + This type represents an externally-managed internal VL. + + * NOTE 1: It is only applicable if the externally-managed VL + is realized by a secondary container cluster network. It + shall + not be present otherwise. + * NOTE 2: A link port is not needed for a VNFC internal + connection point connected to a secondary container cluster + network. + * NOTE 3: An example of the network attachment definition + resource when the container infrastructure service + management is a Kubernetes® instance is a network attachment definition (NAD). + + * NOTE 4: In the case that the cloud native template + included in the MCIOP describes the set of VNFC instances, + an + instance of intCp need not be included for each VNFC instance as all instances would contain the same + information. It is sufficient to include one intCp for the related CPD. The case of using, for a scalable VDU, a + cloud native template in the MCIOP that describes one single VNFC instance is not specified in the present + document version + * NOTE 5: Both "vnfLinkPort" and "netAttDefResource" + attributes can be provided in a "ExtManagedVirtualLinkData" + to indicate + that a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs + type: object + required: + - id + - vnfVirtualLinkDescId + - resourceId + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfVirtualLinkDescId: + description: | + An identifier that is unique within a VNF descriptor. + type: string + vimConnectionId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + netAttDefResourceData: + description: > + Externally provided network attachment definition + resource(s) that provide the specification of the + interface to attach VNFC connection points to this + externallymanaged VL. See notes 1, 3 and 5. + type: array + items: + description: > + This type represents a network attachment definition + resource that provides the specification of the + interface to be used to connect one or multiple + connection points to a secondary container cluster + network realizing a VL. + type: object + required: + - netAttDefResourceId + - resourceHandle + properties: + netAttDefResourceId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + intCp: + description: > + Internal CPs of the VNF to be connected to this + externally-managed VL. See note 1 and 4. + type: array + items: + description: > + This type represents input information related to one + or more VNF internal CP instances created based on the + same CPD. + + NOTE: Cardinality greater than 1 is only applicable + for specific cases where more than one network + attachment + definition resource is needed to fulfil the connectivity requirements of the VNF internal CP, e.g. to build a link + redundant mated pair in SR-IOV cases. When more than one netAttDefResourceId is indicated, all shall + belong to the same namespace as defined by the corresponding "containerNamespace" attribute in the "resourceHandle" attribute + in the "NetAttDefResourceData". + type: object + required: + - cpdId + - netAttDefResourceId + properties: + cpdId: + description: > + An identifier with the intention of being globally + unique. + type: string + netAttDefResourceId: + description: > + Identifiers of the “NetAttDefResourceData” + structure that provides the specification of the + interface to attach the VNF internal CP created + from the CPD identified by cpdId to a secondary + container cluster network. See note. + type: array + items: + description: > + An identifier with the intention of being + globally unique. + type: string + vnfLinkPort: + description: > + Externally provided link ports to be used to connect + VNFC connection points to this externally-managed VL on + this network resource. If this attribute is not present, + the VNFM shall create the link ports on the + externally-managed VL. See notes 2 and 5. + type: array + items: + description: > + This type represents an externally provided link port + to be used to connect a VNFC connection point to an + externally managed VL. + type: object + required: + - vnfLinkPortId + - resourceHandle + properties: + vnfLinkPortId: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceHandle: + required: + - resourceId + type: object + description: > + This type represents the information that allows + addressing a virtualised resource that is used by + a VNF instance. Information about the resource is + available from the VIM. + + * NOTE 1: The value set of the + "vimLevelResourceType" attribute is within the + scope of the VIM or CISM or the resource + provider and can be used as information that complements the ResourceHandle. This value set is different from + the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2). When the container + infrastructure service management is a Kubernetes® instance the vimLevelResourceType is the type of + resource, as would correspond to the 'kind' field if the resource is declared in its own Kubernetes® manifest, + e.g.: Pod, PersistentVolumeClaim, NetworkAttachmentDefinition. + + * NOTE 2: When the container infrastructure + service management is a Kubernetes® instance the + resourceId shall be + populated in the following way: + - For a compute MCIO, it is the instance identifier that Kubernetes® assigns, which is unique cluster wide + per resource type. + - For a storage MCIO modelled as a persistent volume claim, it is the name of the persistent volume claim, + i.e. the value of the 'claimName' field in the Kubernetes® manifest, or a compound name built by + Kubernetes® if the persistent volume claim is defined inline in another template instead of in its own + manifest. + - For a network MCIO representing a NetworkAttachmentDefinition, a Service or an Ingress, it is the value of + the 'metadata.name' field in Kubernetes® manifest. + properties: + vimConnectionId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceProviderId: + description: > + An identifier with the intention of being + globally unique. + type: string + resourceId: + description: > + An identifier maintained by the VIM or the + CISM or other resource provider. It is + expected to be unique within the VIM instance. + type: string + vimLevelResourceType: + description: > + Type of the resource in the scope of the VIM + or the CISM or the resource provider. See note + 1. + type: string + vimLevelAdditionalResourceInfo: + description: > + This type represents additional resource + information which resource and resource type + specific, and which is available from the VIM + or the CISM or the resource provider. + + * NOTE: At least one attribute shall be + present. + type: object + properties: + hostName: + description: > + Name of the host where the resource is + allocated. It shall be present for compute + resources in the scope of the CISM and + shall be absent otherwise. See note. + type: string + persistentVolume: + description: > + Name of the persistent volume to which the + persistent volume claim representing the + storage resource is bound. It may be + present for storage resources in the scope + of the CISM and shall be absent otherwise. + See note. + type: string + additionalInfo: + description: > + This type represents a list of key-value + pairs. The order of the pairs in the list + is not significant. In JSON, a set of + keyvalue pairs is represented as an + object. It shall comply with the + provisions defined in clause 4 of IETF RFC + 8259. In the following example, a list of + key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is + provided to illustrate that the values + associated with different keys can be of + different type. + type: object + containerNamespace: + description: > + The value of the namespace in which the MCIO + corresponding to the resource is deployed. + This attribute shall be present if the + resource is managed by a CISM and it shall be + absent otherwise. + type: string + extManagedMultisiteVirtualLinkId: + description: > + An identifier with the intention of being globally + unique. + type: string + additionalParams: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + - vnfLcmOpOcc + - vnfInstance + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfLcmOpOcc: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualGrant.Get.202: + description: > + 202 ACCEPTED + + + Shall be returned when the process of creating the grant is ongoing, no + grant is available yet. + + The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualGrant.Get.403: + description: | + 403 FORBIDDEN + + Shall be returned upon the following error: The grant + has been rejected. + A ProblemDetails structure shall be included in the + response to provide more details about the rejection in + the "details" attribute. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + diff --git a/v5.3.1/SOL003-VNFPackageManagement-API.json b/v5.3.1/SOL003-VNFPackageManagement-API.json new file mode 100644 index 00000000..02663489 --- /dev/null +++ b/v5.3.1/SOL003-VNFPackageManagement-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL003 - VNF Package Management interface","description":"SOL003 - VNF Package Management interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"2.12.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 003 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/vnfpkgm/v2"},{"url":"https://127.0.0.1/vnfpkgm/v2"}],"paths":{"/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/onboarded_vnf_packages":{"get":{"description":"The GET method queries the information of the VNF packages matching the filter. See clause 10.4.2.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"$ref":"#/components/parameters/filter_vnf_packages"},{"name":"all_fields","description":"Include all complex attributes in the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The NFVO shall support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"fields","description":"Complex attributes to be included into the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The NFVO should support this parameter\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"exclude_fields","description":"Complex attributes to be excluded from the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The NFVO should support this parameter\n","in":"query","required":false,"schema":{"type":"string"}},{"$ref":"#/components/parameters/exclude_default_vnf_packages"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the NFVO if the NFVO supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/OnboardedVnfPackages.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_packages":{"$ref":"#/paths/~1onboarded_vnf_packages"},"/vnf_packages/{vnfPkgId}":{"parameters":[{"$ref":"#/components/parameters/VnfPkgId"}],"get":{"description":"The GET method reads the information of an individual VNF package. Clause 10.4.3.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualVnfPackage.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/onboarded_vnf_packages/{vnfdId}":{"parameters":[{"$ref":"#/components/parameters/VnfdId"}],"get":{"description":"The GET method reads the information of an individual VNF package. Clause 10.4.3.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualOnboardedVnfPackage.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_packages/{vnfPkgId}/vnfd":{"parameters":[{"$ref":"#/components/parameters/VnfPkgId"}],"get":{"description":"The GET method reads the content of the VNFD within a VNF package. See clause 10.4.4.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"$ref":"#/components/parameters/include_signatures_content_of_vnfd"}],"responses":{"200":{"$ref":"#/components/responses/VnfdInIndividualVnfPackage.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/VnfdInIndividualVnfPackage.Get.409"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/onboarded_vnf_packages/{vnfdId}/vnfd":{"parameters":[{"$ref":"#/components/parameters/VnfdId"}],"get":{"description":"The GET method reads the content of the VNFD within a VNF package. See clause 10.4.4.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"$ref":"#/components/parameters/include_signatures_content_of_vnfd"}],"responses":{"200":{"$ref":"#/components/responses/VnfdInIndividualOnboardedVnfPackage.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/VnfdInIndividualOnboardedVnfPackage.Get.409"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_packages/{vnfPkgId}/manifest":{"parameters":[{"$ref":"#/components/parameters/VnfPkgId"}],"get":{"description":"The GET method reads the content of the manifest within a VNF package. See clause 10.4.4a.3.1.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"$ref":"#/components/parameters/include_signatures_content_of_manifest"}],"responses":{"200":{"$ref":"#/components/responses/ManifestInIndividualVnfPackage.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/ManifestInIndividualVnfPackage.Get.406"},"409":{"$ref":"#/components/responses/ManifestInIndividualVnfPackage.Get.409"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/onboarded_vnf_packages/{vnfdId}/manifest":{"parameters":[{"$ref":"#/components/parameters/VnfdId"}],"get":{"description":"The GET method reads the content of the manifest within a VNF package. See clause 10.4.4a.3.1.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"$ref":"#/components/parameters/include_signatures_content_of_manifest"}],"responses":{"200":{"$ref":""},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":""},"409":{"$ref":""},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_packages/{vnfPkgId}/package_content":{"parameters":[{"$ref":"#/components/parameters/VnfPkgId"}],"get":{"description":"The GET method fetches the content of a VNF package identified by the VNF package identifier allocated by the NFVO.\nSee clause 10.4.5.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"$ref":"#/components/parameters/Range"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualVnfPackageContent.Get.200"},"206":{"$ref":"#/components/responses/IndividualVnfPackageContent.Get.206"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/IndividualVnfPackageContent.Get.409"},"416":{"$ref":"#/components/responses/IndividualVnfPackageContent.Get.416"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/onboarded_vnf_packages/{vnfdId}/package_content":{"parameters":[{"$ref":"#/components/parameters/VnfdId"}],"get":{"description":"The GET method fetches the content of a VNF package identified by the VNF package identifier allocated by the NFVO.\nSee clause 10.4.5.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"$ref":"#/components/parameters/Range"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualOnboardedVnfPackageContent.Get.200"},"206":{"$ref":"#/components/responses/IndividualOnboardedVnfPackageContent.Get.206"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/IndividualOnboardedVnfPackageContent.Get.409"},"416":{"$ref":"#/components/responses/IndividualOnboardedVnfPackageContent.Get.416"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_packages/{vnfPkgId}/artifacts":{"parameters":[{"$ref":"#/components/parameters/VnfPkgId"}],"get":{"description":"The GET method shall return an archive that contains a set of artifacts.\n\nThis GET method is used to Bulk-fetch artifacts that are not images.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"$ref":"#/components/parameters/Range"},{"$ref":"#/components/parameters/exclude_all_mano_artifacts"},{"$ref":"#/components/parameters/exclude_all_non_mano_artifacts"},{"$ref":"#/components/parameters/include_external_artifacts"},{"$ref":"#/components/parameters/select_non_mano_artifact_sets"},{"$ref":"#/components/parameters/include_signatures_artifacts"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualVnfPackageArtifacts.Get.200"},"206":{"$ref":"#/components/responses/IndividualVnfPackageArtifacts.Get.206"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/IndividualVnfPackageArtifacts.Get.409"},"416":{"$ref":"#/components/responses/IndividualVnfPackageArtifacts.Get.416"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/onboarded_vnf_packages/{vnfdId}/artifacts":{"parameters":[{"$ref":"#/components/parameters/VnfdId"}],"get":{"description":"The GET method fetches the content of an artifact within a VNF package.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"$ref":"#/components/parameters/Range"},{"$ref":"#/components/parameters/exclude_all_mano_artifacts"},{"$ref":"#/components/parameters/exclude_all_non_mano_artifacts"},{"$ref":"#/components/parameters/include_external_artifacts"},{"$ref":"#/components/parameters/select_non_mano_artifact_sets"},{"$ref":"#/components/parameters/include_signatures_artifacts"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":""},"206":{"$ref":""},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":""},"416":{"$ref":""},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_packages/{vnfPkgId}/artifacts/{artifactPath}":{"parameters":[{"$ref":"#/components/parameters/ArtifactPath"},{"$ref":"#/components/parameters/VnfPkgId"}],"get":{"description":"The GET method fetches the content of an artifact within a VNF package. See clause 10.4.6.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"$ref":"#/components/parameters/Range"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"$ref":"#/components/parameters/include_signatures_content_of_artifact"}],"responses":{"200":{"$ref":"#/components/responses/IndividualVnfPackageArtifact.Get.200"},"206":{"$ref":"#/components/responses/IndividualVnfPackageArtifact.Get.206"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/IndividualVnfPackageArtifact.Get.409"},"416":{"$ref":"#/components/responses/IndividualVnfPackageArtifact.Get.416"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/onboarded_vnf_packages/{vnfdId}/artifacts/{artifactPath}":{"parameters":[{"$ref":"#/components/parameters/ArtifactPath"},{"$ref":"#/components/parameters/VnfdId"}],"get":{"description":"The GET method fetches the content of an artifact within a VNF package. See clause 10.4.6.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"$ref":"#/components/parameters/Range"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"$ref":"#/components/parameters/include_signatures_content_of_artifact"}],"responses":{"200":{"$ref":"#/components/responses/IndividualOnboardedVnfPackageArtifact.Get.200"},"206":{"$ref":"#/components/responses/IndividualOnboardedVnfPackageArtifact.Get.206"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/IndividualOnboardedVnfPackageArtifact.Get.409"},"416":{"$ref":"#/components/responses/IndividualOnboardedVnfPackageArtifact.Get.416"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/subscriptions":{"parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"post":{"description":"The POST method creates a new subscription. See clause 10.4.7.3.1.\n","requestBody":{"$ref":"#/components/requestBodies/PkgmSubscriptionRequest"},"responses":{"201":{"$ref":"#/components/responses/Subscriptions.Post.201"},"303":{"$ref":"#/components/responses/Subscriptions.Post.303"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/Subscriptions.Post.422"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"get":{"description":"The GET method queries the list of active subscriptions of the functional block that invokes the method.\nIt can be used e.g. for resynchronization after error situations. See clause 10.4.7.3.2.\n","parameters":[{"$ref":"#/components/parameters/filter_subscriptions"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the NFVO if the NFVO supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/Subscriptions.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/subscriptions/{subscriptionId}":{"parameters":[{"$ref":"#/components/parameters/SubscriptionId"},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"get":{"description":"The GET method reads an individual subscription. See clause 10.4.8.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualSubscription.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"The DELETE method terminates an individual subscription. See clause 10.4.8.3.5.\n","responses":{"204":{"$ref":"#/components/responses/IndividualSubscription.Delete.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"parameters":{"filter_vnf_packages":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013 [8]. The NFVO shall support receiving this parameter as part of the URI query string. The VNFM may supply this parameter. All attribute names that appear in the VnfPkgInfo and in data types referenced from it shall be supported by the NFVO in the filter expression.\n","in":"query","required":false,"schema":{"type":"string"}},"exclude_default_vnf_packages":{"name":"exclude_default","in":"query","description":"Indicates to exclude the following complex attributes from the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The NFVO shall support this parameter. The following attributes shall be excluded from the VnfPkgInfo structure in the response body if this parameter is provided, or none of the parameters \"all_fields,\" \"fields\", \"exclude_fields\", \"exclude_default\" are provided: - softwareImages\n - additionalArtifacts\n - userDefinedData\n - checksum\n - onboardingFailureDetails.","required":false,"schema":{"type":"string"}},"exclude_all_mano_artifacts":{"name":"exclude_all_mano_artifacts","description":"Flag (i.e. parameter without value) that instructs the NFVO to exclude the set of additional MANO artifacts (i.e. those that are not images) from the response message content. The NFVO shall support this parameter. The VNFM may supply this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},"exclude_all_non_mano_artifacts":{"name":"exclude_all_non_mano_artifacts","description":"Flag (i.e. parameter without value) that instructs the NFVO to exclude the set of non-MANO artifacts from the response message content. The NFVO shall support this parameter. The VNFM may supply this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},"include_external_artifacts":{"name":"include_external_artifacts","description":"Flag (i.e. parameter without value) that instructs the NFVO to include external artifacts in the response message content. It shall not be treated as an error if this flag is provided but there is no external artifact to include in the result. If this parameter is missing, no external artifacts shall be included. The NFVO shall support this parameter. The VNFM may supply this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},"select_non_mano_artifact_sets":{"name":"select_non_mano_artifact_sets","description":"Comma-separated list of non-MANO artifact set identifiers for which the artifacts are to be included in the response body. The NFVO should support this parameter. If the NFVO does not support this parameter, it shall ignore it, i.e. provide a response as if no parameter was provided. The VNFM may supply this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},"include_signatures_artifacts":{"name":"include_signatures","description":"If this parameter is provided, the NFVO shall include in the ZIP archive the individual signatures and, if provided, related certificates for the included artifacts, in the format in which they are provided in the VNF package. If this parameter is not given, the NFVO shall only provide copies of the artifact files. This URI query parameter is a flag, i.e. it shall have no value. The NFVO shall support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},"include_signatures_content_of_artifact":{"name":"include_signatures","description":"If this parameter is provided, the NFVO shall return the artifact and related security information (such as signature and optional certificate) in a ZIP archive. If this parameter is not given, the NFVO shall provide only a copy of the artifact file. This URI query parameter is a flag, i.e. it shall have no value. The NFVO shall support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},"filter_subscriptions":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013 [8]. The NFVO shall support receiving this parameter as part of the URI query string. The VNFM may supply this parameter. All attribute names that appear in the PkgmSubscription and in data types referenced from it shall be supported by the NFVO in the filter expression.\n","in":"query","required":false,"schema":{"type":"string"}},"VnfPkgId":{"name":"vnfPkgId","in":"path","description":"Identifier of the VNF package. The identifier is allocated by the\nNFVO.\nThis identifier can be retrieved from the \"vnfPkgId\" attribute in\nthe VnfPackageOnboardingNotification or\nVnfPackageChangeNotification.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"VnfdId":{"name":"vnfdId","in":"path","description":"Identifier of the VNFD and the VNF package.\nThe identifier is allocated by the VNF provider.\nThis identifier can be retrieved from the \"vnfdId\" attribute\nin the VnfPackageOnboardingNotification or VnfPackageChangeNotification.\nThis identifier can be retrieved from the \"vnfdId\" attribute in the \nVnfPackageOnboardingNotification or VnfPackageChangeNotification.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"ArtifactPath":{"name":"artifactPath","in":"path","description":"SequenceFor an artifact contained as a file in the VNF package,\nthis variable shall contain a sequence of one or more path segments\nrepresenting the path of the artifact within the VNF package,\nrelative to the root of the package.\n\nEXAMPLE: foo/bar/m%40ster.sh\n\nFor an external artifact represented as a URI in the VNF package\nmanifest, this variable shall contain a sequence of one or more path\nsegments as synthesized by the NFVO (see clause 10.5.3.3),\nrepresenting this artifact.\n\nSince multiple path segments are allowed to be contained in this variable,\nthe \"/\" character that separates these segments is not percent-encoded.\nEach individual segment is percent-encoded if necessary as defined in clause\n4.1 of ETSI GS NFV-SOL 013.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"SubscriptionId":{"name":"subscriptionId","in":"path","description":"Identifier of this subscription.\nThis identifier can be retrieved from the resource referenced by\nthe \"Location\" HTTP header in the response to a POST request\ncreating a new \"Individual subscription\" resource. It can also be retrieved from\nthe \"id\" attribute in the message content of that response.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"include_signatures_content_of_vnfd":{"name":"include_signatures","in":"query","description":"If this parameter is provided, the NFVO shall include in the ZIP archive the security\ninformation as specified above.\nThis URI query parameter is a flag, i.e. it shall have no value.\nThe NFVO shall support this parameter.\n","required":false,"schema":{"type":"string"}},"include_signatures_content_of_manifest":{"name":"include_signatures","in":"query","description":"If this parameter is provided, the NFVO shall return the manifest and related\nsecurity information (such as certificate) in a ZIP archive.\nIf this parameter is not given, the NFVO shall provide only a copy of the manifest\nfile.\nThis URI query parameter is a flag, i.e. it shall have no value.\nThe NFVO shall support this parameter.\n","required":false,"schema":{"type":"string"}},"Range":{"name":"Range","in":"header","description":"The request may contain a \"Range\" HTTP header to obtain single\nrange of bytes from the VNF package file. This can be used to\ncontinue an aborted transmission.\n\nIf the \"Range\" header is present in the request and the NFVO\ndoes not support responding to range requests with a 206 response,\nit shall return a 200 OK response instead.\n","required":false,"schema":{"type":"string"}}},"requestBodies":{"PkgmSubscriptionRequest":{"description":"Representation of the created subscription resource.\nThe HTTP response shall include a \"Location\" HTTP header that\npoints to the created subscription resource.\n","content":{"application/json":{"schema":{"description":"This type represents a subscription request related to VNF package management notifications about VNF package on-boarding or changes.\n","type":"object","required":["callbackUri"],"properties":{"filter":{"description":"This type represents a subscription filter related to notifications related to VNF package management.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE 1:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the \n notification types to facilitate automated code generation systems.\nNOTE 2:\tThe attributes \"vnfProductsFromProviders\", \"vnfdId\" and \"vnfPkgId\" are alternatives to reference to \n particular VNF packages in a filter. They should not be used both in the same filter instance, but \n one alternative should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfProductsFromProviders"]},{"required":["vnfdId"]},{"required":["vnfPkgId"]}]}],"properties":{"notificationTypes":{"description":"Match particular notification types. Permitted values: - VnfPackageOnboardingNotification - VnfPackageChangeNotification See note 1.\n","type":"array","items":{"type":"string","enum":["VnfPackageOnboardingNotification","VnfPackageChangeNotification"]}},"vnfProductsFromProviders":{"description":"If present, match VNF packages that contain VNF products from certain providers. See note 2.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF packages that contain VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"versions":{"description":"If present, match VNF packages that contain VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF packages that contain VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfdId":{"description":"Match VNF packages with a VNFD identifier listed in the attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfPkgId":{"description":"Match VNF packages with a package identifier listed in the attribute. May be present if the \"notificationTypes\" attribute contains the value \"VnfPackageChangeNotification\" and shall be absent otherwise. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"operationalState":{"description":"- ENABLED: The VNF package is enabled, i.e. it can be used for the creation of new \"Individual VNF instance\" resources.\n- DISABLED: The VNF package is disabled, i.e. it shall not be used for the creation of further \"Individual VNF instance\" resources\n (unless and until the VNF package is re-enabled).\n","type":"string","enum":["ENABLED","DISABLED"]},"usageState":{"description":"- IN_USE: \"Individual VNF instance\" resources created from this VNF package exist. - NOT_IN_USE: No \"Individual VNF instance\" resource created from this VNF package exists.\n","type":"string","enum":["IN_USE","NOT_IN_USE"]},"vnfmInfo":{"description":"Match strings that specify VNFMs compatible with the VNF. See table 10.5.2.2-1.\n","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE 1 : The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between\n subscriptions. The value of clientPassword should be generated by a random process.\n* NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT which uses mutual authentication based on X.509 certificates, this mode which uses client password to authenticate may be used in the access token request\n toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations\n (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details.\n* NOTE 3: The following values that were included up to version 3.4.1 of the present document have been removed: \"BASIC\" (to signal the use of the basic HTTP authentication) has been removed because it is insecure.\n \"TLS_CERT\" to signal an alternative non-token based authorization method using TLS certificates has been\n removed because the method is no longer supported.\n* NOTE 4: The client certificate is established by means outside the scope of the present document.\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values (see note 3): * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use\n an OAuth 2.0 token, obtained using the client\n credentials grant type after authenticating\n using client identifier and client password\n towards the token endpoint.\n* OAUTH2_CLIENT_CERT: In every HTTP request to the notification endpoint, use an\n OAuth 2.0 token, obtained using the client\n credentials grant type after mutually\n authenticating using client identifier and X.509\n certificates towards the token endpoint.\n","type":"array","items":{"type":"string","enum":["OAUTH2_CLIENT_CREDENTIALS","OAUTH2_CLIENT_CERT"]}},"paramsOauth2ClientCert":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CERT.\nShall be present if authType is \"OAUTH2_CLIENT_CERT\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\n","type":"object","required":["clientId","certificateRef","tokenEndpoint"],"properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint.\n","type":"string"},"certificateRef":{"description":"Fingerprint of the client certificate. The hash function shall use SHA256 or higher. See note 4.\n","type":"string","required":["type","value"],"properties":{"type":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"value":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS.\nShall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\nSee note 2.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"clientPassword":{"description":"Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true}},"responses":{"OnboardedVnfPackages.Get.200":{"description":"200 OK\n\nShall be returned when information about zero or more VNF packages has been queried successfully.\nThe response body shall contain in an array the VNF package info representations that match the\nattribute filter, i.e. zero or more VNF package info representations as defined in clause 10.5.2.2.\nIf the \"filter\" URI parameter or one of the \"all_fields\", \"fields\" (if supported), \"exclude_fields\"\n(if supported) or \"exclude_default\" URI parameters was supplied in the request, the data in the\nresponse body shall have been transformed according to the rules specified in clauses 5.2.2 and\n5.3.2 of ETSI GS NFV-SOL 013, respectively.\nIf the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013\nfor this resource, inclusion of the Link HTTP header in this response shall follow the provisions\nin clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents the information of a VNF package.\nNOTE 1:\tIf the value of the onboardingState attribute is not equal to \"ONBOARDED\", the value of the operationalState \n attribute shall be equal to \"DISABLED\".\nNOTE 2:\tIf the value of the onboardingState attribute is not equal to \"ONBOARDED\", the value of the usageState attribute \n shall be equal to \"NOT_IN_USE\".\nNOTE 3:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n","type":"object","required":["id","onboardingState","operationalState","usageState","vnfmInfo","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfdExtInvariantId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfProductName":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"compatibleSpecificationVersions":{"description":"Indicates which versions of the ETSI GS NFV-SOL 004 specification the package complies to, as defined in the manifest of the package. Each entry shall be formatted as defined in clause 4.3.2 of ETSI GS NFV-SOL 004.\n","type":"array","items":{"description":"A version.\n","type":"string"}},"checksum":{"description":"Cheksum description\n","type":"string"},"packageSecurityOption":{"description":"Signals the security option used by the package as defined in clause 5.1 of ETSI GS NFV-SOL 004. It shall be present after the VNF package content has been on-boarded and absent otherwise. Valid values: OPTION_1, OPTION_2\n","type":"string","enum":["OPTION_1","OPTION_2"]},"signingCertificate":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"softwareImages":{"description":"Information about VNF package artifacts that are software images. This attribute shall not be present before the VNF package content is on-boarded. Otherwise, this attribute shall be present unless it has been requested to be excluded per attribute selector.\n","type":"array","items":{"description":"This type represents an artifact contained in or external to a VNF package which represents a software image..\n* NOTE 1:\tThe list of permitted values was taken from \"Container formats\" in OpenStack® documentation: \"Disk and container formats for images\"\n (Available at https://docs.openstack.org/glance/pike/user/formats.html).\n* NOTE 2:\tThe list of permitted values was adapted from \"Disk formats\" in OpenStack® documentation: \"Disk and container formats for images\"\n (Available at https://docs.openstack.org/glance/pike/user/formats.html).\n* NOTE 3: The attribute shall be present for VM-based software images referenced from a Vdu, and shall be absent\n otherwise.\n* NOTE 4: The attribute shall be present for software images referenced from a VirtualStorageDesc, and shall be absent\n otherwise.\n","type":"object","required":["id","name","provider","version","checksum","isEncrypted","containerFormat","createdAt","size"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"provider":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"version":{"description":"A version.\n","type":"string"},"checksum":{"description":"Cheksum description\n","type":"string"},"isEncrypted":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"containerFormat":{"description":"Container format indicates whether the software image is in a file format that also contains metadata about the actual software. Permitted values: - AKI: a kernel image format - AMI: a machine image format - ARI: a ramdisk image format - BARE: the image does not have a container or metadata envelope - DOCKER: docker container format - OVA: OVF package in a tarfile - OVF: OVF container format See note 1.\n","type":"string","enum":["AKI","AMI","ARI","BARE","DOCKER","OVA","OVF"]},"diskFormat":{"description":"Disk format of a software image is the format of the underlying disk image. Permitted values: - AKI: a kernel image format\n - AMI: a machine image format\n - ARI: a ramdisk image format\n - ISO: an archive format for the data contents of an optical disc,\n such as CD-ROM\n - QCOW2: a common disk image format, which can expand dynamically\n and supports copy on write\n - RAW: an unstructured disk image format\n - VDI: a common disk image format\n - VHD: a common disk image format\n - VHDX: enhanced version of VHD format\n - VMDK: a common disk image format\nSee notes 2 and 3.\n","type":"string","enum":["AKI","AMI","ISO","QCOW2","RAW","VDI","VHD","VHDX","VMDK"]},"createdAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"minDisk":{"description":"The minimal disk for this software image in bytes. See note 4.\n","type":"integer"},"minRam":{"description":"The minimal RAM for this software image in bytes. See note 3.\n","type":"integer"},"size":{"description":"Size of this software image in bytes.\n","type":"integer"},"userMetadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"imagePath":{"description":"Path which identifies the image artifact and also allows to access a copy of the image artifact. For a software image contained as a file in the VNF package, this attribute shall be present, and the value of this attribute shall start with the name of the first segment in the path in the package, i.e., it shall not be prefixed by path separator characters such as \".\" and \"/\". EXAMPLE: foo/bar/m%40ster.vhd For an external software image represented as a URI in the VNF descriptor, this attribute shall be present if the image artifact has been downloaded by the NFVO and shall be absent otherwise. If present, it shall contain the artifactPath under which the image artifact can be obtained using the \"Individual artifact in a VNF package\" resource defined in clause 9.4.7. It is the responsibility of the NFVO to synthesize this path in a manner that avoids any collision of the synthesized artifact path with the paths and names of image artifacts included in the package.\n","type":"string"},"imageUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}},"additionalArtifacts":{"description":"Information about VNF package artifacts contained in the VNF package that are not software images. Every local and external artifact declared in the manifest shall be included, except the software images and the files that make up the parts of the VNFD (see clause 10.4.4.3.2). Signature files and certificate files are not considered as artifacts, however, the content of the \"Licenses\" and \"Testing\" directories in the VNF package is. This attribute shall not be present before the VNF package content is on-boarded. Otherwise, this attribute shall be present if the VNF package contains additional artifacts.\n","type":"array","items":{"description":"This type represents an artifact other than a software image which is contained in or external to a VNF package.\n* NOTE: The attribute name \"artifactURI\" does not comply with the naming convention defined in clause 4.3 in ETSI GS NFV-SOL 015. This is to maintain the backward compatibility.\n","type":"object","required":["artifactPath","checksum","isEncrypted"],"properties":{"artifactPath":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"artifactURI":{"description":"URI of the artifact as defined in the VNF package manifest. Shall be present if the artifact is external to the package and shall be absent otherwise. EXAMPLE:https://example.com/m%40ster.sh See note.\n","type":"array","items":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"checksum":{"description":"Cheksum description\n","type":"string"},"isEncrypted":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"nonManoArtifactSetId":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"artifactClassification":{"description":"Marks specific types of artifacts as defined in the VNF package. If none of the specific classes listed below applies, the attribute shall not be present.\nValid values: -\tHISTORY: a history artifact as per clause 4.3.3 in ETSI GS NFV-SOL 004 -\tTESTING: a testing artifact as per clause 4.3.4 in ETSI GS NFV-SOL 004 -\tLICENSE: a license artifact as per clause 4.3.5 in ETSI GS NFV-SOL 004\n","type":"string","enum":["HISTORY","TESTING","LICENSE"]},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"onboardingState":{"description":"CREATED: The \"Individual VNF package\" resource has been created. UPLOADING: The associated VNF package content is being uploaded. PROCESSING: The associated VNF package content is being processed, e.g., validation.\nONBOARDED: The associated VNF package content has been on-boarded successfully. ERROR: There was an error during upload of the VNF package content or external artifacts, or during VNF package processing.\n","type":"string","enum":["CREATED","UPLOADING","PROCESSING","ONBOARDED","ERROR"]},"operationalState":{"description":"- ENABLED: The VNF package is enabled, i.e. it can be used for the creation of new \"Individual VNF instance\" resources.\n- DISABLED: The VNF package is disabled, i.e. it shall not be used for the creation of further \"Individual VNF instance\" resources\n (unless and until the VNF package is re-enabled).\n","type":"string","enum":["ENABLED","DISABLED"]},"usageState":{"description":"- IN_USE: \"Individual VNF instance\" resources created from this VNF package exist. - NOT_IN_USE: No \"Individual VNF instance\" resource created from this VNF package exists.\n","type":"string","enum":["IN_USE","NOT_IN_USE"]},"vnfmInfo":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"onboardingFailureDetails":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self","packageContent"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfd":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"packageContent":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"IndividualVnfPackage.Get.200":{"description":"200 OK\n\nShall be returned when information of the VNF package has been read successfully.\nThe response body shall contain the VNF package info representation defined in clause 10.5.2.2.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents the information of a VNF package.\nNOTE 1:\tIf the value of the onboardingState attribute is not equal to \"ONBOARDED\", the value of the operationalState \n attribute shall be equal to \"DISABLED\".\nNOTE 2:\tIf the value of the onboardingState attribute is not equal to \"ONBOARDED\", the value of the usageState attribute \n shall be equal to \"NOT_IN_USE\".\nNOTE 3:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n","type":"object","required":["id","onboardingState","operationalState","usageState","vnfmInfo","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfdExtInvariantId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfProductName":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"compatibleSpecificationVersions":{"description":"Indicates which versions of the ETSI GS NFV-SOL 004 specification the package complies to, as defined in the manifest of the package. Each entry shall be formatted as defined in clause 4.3.2 of ETSI GS NFV-SOL 004.\n","type":"array","items":{"description":"A version.\n","type":"string"}},"checksum":{"description":"Cheksum description\n","type":"string"},"packageSecurityOption":{"description":"Signals the security option used by the package as defined in clause 5.1 of ETSI GS NFV-SOL 004. It shall be present after the VNF package content has been on-boarded and absent otherwise. Valid values: OPTION_1, OPTION_2\n","type":"string","enum":["OPTION_1","OPTION_2"]},"signingCertificate":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"softwareImages":{"description":"Information about VNF package artifacts that are software images. This attribute shall not be present before the VNF package content is on-boarded. Otherwise, this attribute shall be present unless it has been requested to be excluded per attribute selector.\n","type":"array","items":{"description":"This type represents an artifact contained in or external to a VNF package which represents a software image..\n* NOTE 1:\tThe list of permitted values was taken from \"Container formats\" in OpenStack® documentation: \"Disk and container formats for images\"\n (Available at https://docs.openstack.org/glance/pike/user/formats.html).\n* NOTE 2:\tThe list of permitted values was adapted from \"Disk formats\" in OpenStack® documentation: \"Disk and container formats for images\"\n (Available at https://docs.openstack.org/glance/pike/user/formats.html).\n* NOTE 3: The attribute shall be present for VM-based software images referenced from a Vdu, and shall be absent\n otherwise.\n* NOTE 4: The attribute shall be present for software images referenced from a VirtualStorageDesc, and shall be absent\n otherwise.\n","type":"object","required":["id","name","provider","version","checksum","isEncrypted","containerFormat","createdAt","size"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"provider":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"version":{"description":"A version.\n","type":"string"},"checksum":{"description":"Cheksum description\n","type":"string"},"isEncrypted":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"containerFormat":{"description":"Container format indicates whether the software image is in a file format that also contains metadata about the actual software. Permitted values: - AKI: a kernel image format - AMI: a machine image format - ARI: a ramdisk image format - BARE: the image does not have a container or metadata envelope - DOCKER: docker container format - OVA: OVF package in a tarfile - OVF: OVF container format See note 1.\n","type":"string","enum":["AKI","AMI","ARI","BARE","DOCKER","OVA","OVF"]},"diskFormat":{"description":"Disk format of a software image is the format of the underlying disk image. Permitted values: - AKI: a kernel image format\n - AMI: a machine image format\n - ARI: a ramdisk image format\n - ISO: an archive format for the data contents of an optical disc,\n such as CD-ROM\n - QCOW2: a common disk image format, which can expand dynamically\n and supports copy on write\n - RAW: an unstructured disk image format\n - VDI: a common disk image format\n - VHD: a common disk image format\n - VHDX: enhanced version of VHD format\n - VMDK: a common disk image format\nSee notes 2 and 3.\n","type":"string","enum":["AKI","AMI","ISO","QCOW2","RAW","VDI","VHD","VHDX","VMDK"]},"createdAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"minDisk":{"description":"The minimal disk for this software image in bytes. See note 4.\n","type":"integer"},"minRam":{"description":"The minimal RAM for this software image in bytes. See note 3.\n","type":"integer"},"size":{"description":"Size of this software image in bytes.\n","type":"integer"},"userMetadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"imagePath":{"description":"Path which identifies the image artifact and also allows to access a copy of the image artifact. For a software image contained as a file in the VNF package, this attribute shall be present, and the value of this attribute shall start with the name of the first segment in the path in the package, i.e., it shall not be prefixed by path separator characters such as \".\" and \"/\". EXAMPLE: foo/bar/m%40ster.vhd For an external software image represented as a URI in the VNF descriptor, this attribute shall be present if the image artifact has been downloaded by the NFVO and shall be absent otherwise. If present, it shall contain the artifactPath under which the image artifact can be obtained using the \"Individual artifact in a VNF package\" resource defined in clause 9.4.7. It is the responsibility of the NFVO to synthesize this path in a manner that avoids any collision of the synthesized artifact path with the paths and names of image artifacts included in the package.\n","type":"string"},"imageUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}},"additionalArtifacts":{"description":"Information about VNF package artifacts contained in the VNF package that are not software images. Every local and external artifact declared in the manifest shall be included, except the software images and the files that make up the parts of the VNFD (see clause 10.4.4.3.2). Signature files and certificate files are not considered as artifacts, however, the content of the \"Licenses\" and \"Testing\" directories in the VNF package is. This attribute shall not be present before the VNF package content is on-boarded. Otherwise, this attribute shall be present if the VNF package contains additional artifacts.\n","type":"array","items":{"description":"This type represents an artifact other than a software image which is contained in or external to a VNF package.\n* NOTE: The attribute name \"artifactURI\" does not comply with the naming convention defined in clause 4.3 in ETSI GS NFV-SOL 015. This is to maintain the backward compatibility.\n","type":"object","required":["artifactPath","checksum","isEncrypted"],"properties":{"artifactPath":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"artifactURI":{"description":"URI of the artifact as defined in the VNF package manifest. Shall be present if the artifact is external to the package and shall be absent otherwise. EXAMPLE:https://example.com/m%40ster.sh See note.\n","type":"array","items":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"checksum":{"description":"Cheksum description\n","type":"string"},"isEncrypted":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"nonManoArtifactSetId":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"artifactClassification":{"description":"Marks specific types of artifacts as defined in the VNF package. If none of the specific classes listed below applies, the attribute shall not be present.\nValid values: -\tHISTORY: a history artifact as per clause 4.3.3 in ETSI GS NFV-SOL 004 -\tTESTING: a testing artifact as per clause 4.3.4 in ETSI GS NFV-SOL 004 -\tLICENSE: a license artifact as per clause 4.3.5 in ETSI GS NFV-SOL 004\n","type":"string","enum":["HISTORY","TESTING","LICENSE"]},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"onboardingState":{"description":"CREATED: The \"Individual VNF package\" resource has been created. UPLOADING: The associated VNF package content is being uploaded. PROCESSING: The associated VNF package content is being processed, e.g., validation.\nONBOARDED: The associated VNF package content has been on-boarded successfully. ERROR: There was an error during upload of the VNF package content or external artifacts, or during VNF package processing.\n","type":"string","enum":["CREATED","UPLOADING","PROCESSING","ONBOARDED","ERROR"]},"operationalState":{"description":"- ENABLED: The VNF package is enabled, i.e. it can be used for the creation of new \"Individual VNF instance\" resources.\n- DISABLED: The VNF package is disabled, i.e. it shall not be used for the creation of further \"Individual VNF instance\" resources\n (unless and until the VNF package is re-enabled).\n","type":"string","enum":["ENABLED","DISABLED"]},"usageState":{"description":"- IN_USE: \"Individual VNF instance\" resources created from this VNF package exist. - NOT_IN_USE: No \"Individual VNF instance\" resource created from this VNF package exists.\n","type":"string","enum":["IN_USE","NOT_IN_USE"]},"vnfmInfo":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"onboardingFailureDetails":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self","packageContent"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfd":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"packageContent":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualOnboardedVnfPackage.Get.200":{"description":"200 OK\n\nShall be returned when information of the VNF package has been read successfully.\nThe response body shall contain the VNF package info representation defined in clause 10.5.2.2.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents the information of a VNF package.\nNOTE 1:\tIf the value of the onboardingState attribute is not equal to \"ONBOARDED\", the value of the operationalState \n attribute shall be equal to \"DISABLED\".\nNOTE 2:\tIf the value of the onboardingState attribute is not equal to \"ONBOARDED\", the value of the usageState attribute \n shall be equal to \"NOT_IN_USE\".\nNOTE 3:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n","type":"object","required":["id","onboardingState","operationalState","usageState","vnfmInfo","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfdExtInvariantId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfProductName":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersion":{"description":"A version.\n","type":"string"},"compatibleSpecificationVersions":{"description":"Indicates which versions of the ETSI GS NFV-SOL 004 specification the package complies to, as defined in the manifest of the package. Each entry shall be formatted as defined in clause 4.3.2 of ETSI GS NFV-SOL 004.\n","type":"array","items":{"description":"A version.\n","type":"string"}},"checksum":{"description":"Cheksum description\n","type":"string"},"packageSecurityOption":{"description":"Signals the security option used by the package as defined in clause 5.1 of ETSI GS NFV-SOL 004. It shall be present after the VNF package content has been on-boarded and absent otherwise. Valid values: OPTION_1, OPTION_2\n","type":"string","enum":["OPTION_1","OPTION_2"]},"signingCertificate":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"softwareImages":{"description":"Information about VNF package artifacts that are software images. This attribute shall not be present before the VNF package content is on-boarded. Otherwise, this attribute shall be present unless it has been requested to be excluded per attribute selector.\n","type":"array","items":{"description":"This type represents an artifact contained in or external to a VNF package which represents a software image..\n* NOTE 1:\tThe list of permitted values was taken from \"Container formats\" in OpenStack® documentation: \"Disk and container formats for images\"\n (Available at https://docs.openstack.org/glance/pike/user/formats.html).\n* NOTE 2:\tThe list of permitted values was adapted from \"Disk formats\" in OpenStack® documentation: \"Disk and container formats for images\"\n (Available at https://docs.openstack.org/glance/pike/user/formats.html).\n* NOTE 3: The attribute shall be present for VM-based software images referenced from a Vdu, and shall be absent\n otherwise.\n* NOTE 4: The attribute shall be present for software images referenced from a VirtualStorageDesc, and shall be absent\n otherwise.\n","type":"object","required":["id","name","provider","version","checksum","isEncrypted","containerFormat","createdAt","size"],"properties":{"id":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"name":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"provider":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"version":{"description":"A version.\n","type":"string"},"checksum":{"description":"Cheksum description\n","type":"string"},"isEncrypted":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"containerFormat":{"description":"Container format indicates whether the software image is in a file format that also contains metadata about the actual software. Permitted values: - AKI: a kernel image format - AMI: a machine image format - ARI: a ramdisk image format - BARE: the image does not have a container or metadata envelope - DOCKER: docker container format - OVA: OVF package in a tarfile - OVF: OVF container format See note 1.\n","type":"string","enum":["AKI","AMI","ARI","BARE","DOCKER","OVA","OVF"]},"diskFormat":{"description":"Disk format of a software image is the format of the underlying disk image. Permitted values: - AKI: a kernel image format\n - AMI: a machine image format\n - ARI: a ramdisk image format\n - ISO: an archive format for the data contents of an optical disc,\n such as CD-ROM\n - QCOW2: a common disk image format, which can expand dynamically\n and supports copy on write\n - RAW: an unstructured disk image format\n - VDI: a common disk image format\n - VHD: a common disk image format\n - VHDX: enhanced version of VHD format\n - VMDK: a common disk image format\nSee notes 2 and 3.\n","type":"string","enum":["AKI","AMI","ISO","QCOW2","RAW","VDI","VHD","VHDX","VMDK"]},"createdAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"minDisk":{"description":"The minimal disk for this software image in bytes. See note 4.\n","type":"integer"},"minRam":{"description":"The minimal RAM for this software image in bytes. See note 3.\n","type":"integer"},"size":{"description":"Size of this software image in bytes.\n","type":"integer"},"userMetadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"imagePath":{"description":"Path which identifies the image artifact and also allows to access a copy of the image artifact. For a software image contained as a file in the VNF package, this attribute shall be present, and the value of this attribute shall start with the name of the first segment in the path in the package, i.e., it shall not be prefixed by path separator characters such as \".\" and \"/\". EXAMPLE: foo/bar/m%40ster.vhd For an external software image represented as a URI in the VNF descriptor, this attribute shall be present if the image artifact has been downloaded by the NFVO and shall be absent otherwise. If present, it shall contain the artifactPath under which the image artifact can be obtained using the \"Individual artifact in a VNF package\" resource defined in clause 9.4.7. It is the responsibility of the NFVO to synthesize this path in a manner that avoids any collision of the synthesized artifact path with the paths and names of image artifacts included in the package.\n","type":"string"},"imageUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}},"additionalArtifacts":{"description":"Information about VNF package artifacts contained in the VNF package that are not software images. Every local and external artifact declared in the manifest shall be included, except the software images and the files that make up the parts of the VNFD (see clause 10.4.4.3.2). Signature files and certificate files are not considered as artifacts, however, the content of the \"Licenses\" and \"Testing\" directories in the VNF package is. This attribute shall not be present before the VNF package content is on-boarded. Otherwise, this attribute shall be present if the VNF package contains additional artifacts.\n","type":"array","items":{"description":"This type represents an artifact other than a software image which is contained in or external to a VNF package.\n* NOTE: The attribute name \"artifactURI\" does not comply with the naming convention defined in clause 4.3 in ETSI GS NFV-SOL 015. This is to maintain the backward compatibility.\n","type":"object","required":["artifactPath","checksum","isEncrypted"],"properties":{"artifactPath":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"artifactURI":{"description":"URI of the artifact as defined in the VNF package manifest. Shall be present if the artifact is external to the package and shall be absent otherwise. EXAMPLE:https://example.com/m%40ster.sh See note.\n","type":"array","items":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}},"checksum":{"description":"Cheksum description\n","type":"string"},"isEncrypted":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"nonManoArtifactSetId":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"artifactClassification":{"description":"Marks specific types of artifacts as defined in the VNF package. If none of the specific classes listed below applies, the attribute shall not be present.\nValid values: -\tHISTORY: a history artifact as per clause 4.3.3 in ETSI GS NFV-SOL 004 -\tTESTING: a testing artifact as per clause 4.3.4 in ETSI GS NFV-SOL 004 -\tLICENSE: a license artifact as per clause 4.3.5 in ETSI GS NFV-SOL 004\n","type":"string","enum":["HISTORY","TESTING","LICENSE"]},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"onboardingState":{"description":"CREATED: The \"Individual VNF package\" resource has been created. UPLOADING: The associated VNF package content is being uploaded. PROCESSING: The associated VNF package content is being processed, e.g., validation.\nONBOARDED: The associated VNF package content has been on-boarded successfully. ERROR: There was an error during upload of the VNF package content or external artifacts, or during VNF package processing.\n","type":"string","enum":["CREATED","UPLOADING","PROCESSING","ONBOARDED","ERROR"]},"operationalState":{"description":"- ENABLED: The VNF package is enabled, i.e. it can be used for the creation of new \"Individual VNF instance\" resources.\n- DISABLED: The VNF package is disabled, i.e. it shall not be used for the creation of further \"Individual VNF instance\" resources\n (unless and until the VNF package is re-enabled).\n","type":"string","enum":["ENABLED","DISABLED"]},"usageState":{"description":"- IN_USE: \"Individual VNF instance\" resources created from this VNF package exist. - NOT_IN_USE: No \"Individual VNF instance\" resource created from this VNF package exists.\n","type":"string","enum":["IN_USE","NOT_IN_USE"]},"vnfmInfo":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"onboardingFailureDetails":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self","packageContent"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfd":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"packageContent":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"VnfdInIndividualVnfPackage.Get.200":{"description":"200 OK\n\nShall be returned when the content of the VNFD has been read successfully.\nThe message content shall contain a copy of the file representing the VNFD or\na ZIP file that contains the file or multiple files representing the VNFD,\nas specified above.\nThe \"Content-Type\" HTTP header shall be set according to the format of the\nreturned file, i.e. to \"text/plain\" for a YAML file or to \"application/zip\"\nfor a ZIP file.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"required":true,"schema":{"type":"string","enum":["text/plain","application/zip"]}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"VnfdInIndividualVnfPackage.Get.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a conflict\nwith the state of the resource.\nTypically, this is due to the fact that \"onboardingState\"\nof the VNF package has a value different from\n\"ONBOARDED\".\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"VnfdInIndividualOnboardedVnfPackage.Get.200":{"description":"200 OK\n\nShall be returned when the content of the VNFD has been read successfully.\nThe message content shall contain a copy of the file representing the VNFD or\na ZIP file that contains the file or multiple files representing the VNFD,\nas specified above.\nThe \"Content-Type\" HTTP header shall be set according to the format of the\nreturned file, i.e. to \"text/plain\" for a YAML file or to \"application/zip\"\nfor a ZIP file.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"required":true,"schema":{"type":"string","enum":["text/plain","application/zip"]}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"VnfdInIndividualOnboardedVnfPackage.Get.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a conflict\nwith the state of the resource.\nTypically, this is due to the fact that \"onboardingState\"\nof the VNF package has a value different from\n\"ONBOARDED\".\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"ManifestInIndividualVnfPackage.Get.200":{"description":"200 OK\n\nShall be returned when the content of the manifest has been read successfully.\nIf the \"include_signatures\" URI query parameter was absent in the request,\nor if the manifest file has all security-related information embedded\n(i.e. there is no separate certificate file), the message content shall contain\na copy of the manifest file of the VNF package and the \"Content-Type\" HTTP\nheader shall be set to \"text/plain\".\n\nIf the \"include_signatures\" URI query parameter was present in the related\nrequest and the manifest file does not have all the security-related\ninformation embedded (i.e. there is a separate certificate file),\nthe \"Content-Type\" HTTP header shall be set to \"application/zip and the\nmessage content shall contain a ZIP archive which includes:\n•\ta copy of the manifest file of the VNF package;\n•\ta copy of the related individual certificate file.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"required":true,"schema":{"type":"string","enum":["text/plain","application/zip"]}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"ManifestInIndividualVnfPackage.Get.406":{"description":"406 Not Acceptable\n\nIf the related request contained an \"Accept\" header\nnot compatible with the Content type \"application/zip\"\nbut the \"include_signatures\" flag was provided, the\nNFVO shall respond with this response code.\nThe \"ProblemDetails\" structure may be included with\nthe \"detail\" attribute providing more information about\nthe error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}}},"ManifestInIndividualVnfPackage.Get.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that \"onboardingState\"\nof the VNF package has a value different from\n\"ONBOARDED\".\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"ManifestInIndividualOnboardedVnfPackage.Get.200":{"description":"200 OK\n\nShall be returned when the content of the manifest has been read successfully.\nIf the \"include_signatures\" URI query parameter was absent in the request,\nor if the manifest file has all security-related information embedded\n(i.e. there is no separate certificate file), the message content shall contain\na copy of the manifest file of the VNF package and the \"Content-Type\" HTTP\nheader shall be set to \"text/plain\".\n\nIf the \"include_signatures\" URI query parameter was present in the related\nrequest and the manifest file does not have all the security-related\ninformation embedded (i.e. there is a separate certificate file),\nthe \"Content-Type\" HTTP header shall be set to \"application/zip and the\nmessage content shall contain a ZIP archive which includes:\n•\ta copy of the manifest file of the VNF package;\n•\ta copy of the related individual certificate file.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"required":true,"schema":{"type":"string","enum":["text/plain","application/zip"]}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"ManifestInIndividualOnboardedVnfPackage.Get.406":{"description":"406 Not Acceptable\n\nIf the related request contained an \"Accept\" header\nnot compatible with the Content type \"application/zip\"\nbut the \"include_signatures\" flag was provided, the\nNFVO shall respond with this response code.\nThe \"ProblemDetails\" structure may be included with\nthe \"detail\" attribute providing more information about\nthe error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}}},"ManifestInIndividualOnboardedVnfPackage.Get.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that \"onboardingState\"\nof the VNF package has a value different from\n\"ONBOARDED\".\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualVnfPackageContent.Get.200":{"description":"200 OK\n\nShall be returned when the whole content of the VNF package file has been read successfully.\nThe response body shall include a copy of the VNF package file.\nThe \"Content-Type HTTP\" header shall be set according to the type of the file,\ni.e. to \"application/zip\" for a VNF Package as defined in ETSI GS NFV SOL 004.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualVnfPackageContent.Get.206":{"description":"206 PARTIAL CONTENT\n\nIf the NFVO supports range requests, this response shall be returned when\na single consecutive byte range from the content of the VNF package file\nhas been read successfully according to the request.\nThe response body shall contain the requested part of the VNF package file.\nThe \"Content-Range\" HTTP header shall be provided according to IETF RFC 9110 [16].\nThe \"Content-Type\" HTTP header shall be set as defined above for the \"200 OK\" response.\n","headers":{"Content-Range":{"required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualVnfPackageContent.Get.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that\n\"onboardingState\" of the VNF package has a value\ndifferent from \"ONBOARDED\".\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualVnfPackageContent.Get.416":{"description":"416 Range Not Satisfiable\n\nShall be returned upon the following error: The byte\nrange passed in the \"Range\" header did not match\nany available byte range in the VNF package file\n(e.g. \"access after end of file\").\nThe response body may contain a ProblemDetails\nstructure\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualOnboardedVnfPackageContent.Get.200":{"description":"200 OK\n\nShall be returned when the whole content of the VNF package file has been read successfully.\nThe response body shall include a copy of the VNF package file.\nThe \"Content-Type HTTP\" header shall be set according to the type of the file,\ni.e. to \"application/zip\" for a VNF Package as defined in ETSI GS NFV SOL 004.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualOnboardedVnfPackageContent.Get.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that\n\"onboardingState\" of the VNF package has a value\ndifferent from \"ONBOARDED\".\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualOnboardedVnfPackageContent.Get.416":{"description":"416 Range Not Satisfiable\n\nShall be returned upon the following error: The byte\nrange passed in the \"Range\" header did not match\nany available byte range in the VNF package file\n(e.g. \"access after end of file\").\nThe response body may contain a ProblemDetails\nstructure\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualVnfPackageArtifact.Get.200":{"description":"200 OK\n\nShall be returned when the whole content of the artifact file has\nbeen read successfully.\n\nIf the \"include_signatures\" request URI parameter was not provided in\nthe related request, the message content shall contain a copy of the artifact\nfile from the VNF package, as defined by ETSI GS NFV-SOL 004 and the \"Content-Type\"\nHTTP header shall be set according to the content type of the artifact file.\nIf the artifact is encrypted, the header shall be set to the value \"application/cms\"\n(IETF RFC 7193). If the content type cannot be determined, the header shall be set\nto the value \"application/octet-stream\".\n\nIf the \"include_signatures\" request URI parameter was provided in the related request,\nthe \"Content-Type\" HTTP header shall be set to \"application/zip and the message content\nshall contain a ZIP archive which includes:\n•\ta copy of the artifact file from the VNF package, as defined by ETSI GS NFV SOL 004;\n•\tthe related security information (individual signature file and optional related\n individual certificate file).\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.\nThe \"Content-Type\" HTTP header shall be set according to the\ncontent type of the artifact file. If the content type cannot\nbe determined, the header shall be set to the value\n\"application/octet-stream\".\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualVnfPackageArtifact.Get.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that\n\"onboardingState\" of the VNF package has a value\ndifferent from \"ONBOARDED\".\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualVnfPackageArtifact.Get.416":{"description":"416 Range Not Satisfiable\n\nShall be returned upon the following error: The byte\nrange passed in the \"Range\" header did not match\nany available byte range in the artifact file\n(e.g. \"access after end of file\").\nThe response body may contain a ProblemDetails\nstructure\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualOnboardedVnfPackageArtifact.Get.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that\n\"onboardingState\" of the VNF package has a value\ndifferent from \"ONBOARDED\".\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualOnboardedVnfPackageArtifact.Get.416":{"description":"416 Range Not Satisfiable\n\nShall be returned upon the following error: The byte\nrange passed in the \"Range\" header did not match\nany available byte range in the artifact file\n(e.g. \"access after end of file\").\nThe response body may contain a ProblemDetails\nstructure\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualVnfPackageArtifacts.Get.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that\n\"onboardingState\" of the VNF package has a value\ndifferent from \"ONBOARDED\".\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualVnfPackageArtifacts.Get.416":{"description":"416 Range Not Satisfiable\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that\n\"onboardingState\" of the VNF package has a value\ndifferent from \"ONBOARDED\".\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualOnboardedVnfPackageArtifacts.Get.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that\n\"onboardingState\" of the VNF package has a value\ndifferent from \"ONBOARDED\".\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualOnboardedVnfPackageArtifacts.Get.416":{"description":"416 Range Not Satisfiable\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact that\n\"onboardingState\" of the VNF package has a value\ndifferent from \"ONBOARDED\".\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualOnboardedVnfPackageContent.Get.206":{"description":"206 PARTIAL CONTENT\n\nIf the NFVO supports range requests, this response shall be returned when\na single consecutive byte range from the content of the VNF package file\nhas been read successfully according to the request.\nThe response body shall contain the requested part of the VNF package file.\nThe \"Content-Range\" HTTP header shall be provided according to IETF RFC 9110 [16].\nThe \"Content-Type\" HTTP header shall be set as defined above for the \"200 OK\" response.\n","headers":{"Content-Range":{"required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"required":true,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualVnfPackageArtifacts.Get.200":{"description":"200 OK\n\nShall be returned when the whole content of the archive containing\nthe artifact files has been read successfully.\nThe message content shall be a ZIP archive containing the requested\nset of artifacts selected according to the provisions specified above\nin this clause, and, if the flag \"include_signatures\" was provided in\nthe related request, the applicable signature files and, if available,\nthe separate certificate files from the VNF package.\nThe \"Content-Type\" HTTP header shall be set to \"application/zip\".\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.\nThe \"Content-Type\" HTTP header shall be set according to the\ncontent type of the artifact file. If the content type cannot\nbe determined, the header shall be set to the value\n\"application/octet-stream\".\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualVnfPackageArtifact.Get.206":{"description":"206 PARTIAL CONTENT\n\nIf the NFVO supports range requests and the \"include_signatures\" request\nURI parameter was not present in the related request, this response shall\nbe returned when a single consecutive byte range from the content of the\nartifact file, if the NFVO supports range requests has been read successfully\naccording to the request.\nThe response body shall contain the requested part of the VNF\npackage file.\nThe \"Content-Range\" HTTP header shall be provided according to\nIETF RFC 9110 [18].\nThe \"Content-Type\" HTTP header shall be set as defined above for\nthe \"200 OK\" response.\n","headers":{"Content-Range":{"required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"required":true,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualVnfPackageArtifacts.Get.206":{"description":"206 PARTIAL CONTENT\n\nIf the NFVO supports range requests, this response shall be returned\nwhen a single consecutive byte range from the content of the archive\nthat would have been returned in a \"200 OK\" response has been read\nsuccessfully according to the request.\nThe response body shall contain the requested part of the archive.\nThe \"Content-Type\" HTTP header shall be set to \"application/zip\".\nThe \"Content-Range\" HTTP header shall be provided according to IETF RFC 9110 [17].\n","headers":{"Content-Range":{"required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.\nThe \"Content-Type\" HTTP header shall be set according to the\ncontent type of the artifact file. If the content type cannot\nbe determined, the header shall be set to the value\n\"application/octet-stream\".\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualOnboardedVnfPackageArtifacts.Get.200":{"description":"200 OK\n\nShall be returned when the whole content of the archive containing\nthe artifact files has been read successfully.\nThe message content shall be a ZIP archive containing the requested\nset of artifacts selected according to the provisions specified above\nin this clause, and, if the flag \"include_signatures\" was provided in\nthe related request, the applicable signature files and, if available,\nthe separate certificate files from the VNF package.\nThe \"Content-Type\" HTTP header shall be set to \"application/zip\".\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.\nThe \"Content-Type\" HTTP header shall be set according to the\ncontent type of the artifact file. If the content type cannot\nbe determined, the header shall be set to the value\n\"application/octet-stream\".\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualOnboardedVnfPackageArtifacts.Get.206":{"description":"206 PARTIAL CONTENT\n\nIf the NFVO supports range requests, this response shall be returned\nwhen a single consecutive byte range from the content of the archive\nthat would have been returned in a \"200 OK\" response has been read\nsuccessfully according to the request.\nThe response body shall contain the requested part of the archive.\nThe \"Content-Type\" HTTP header shall be set to \"application/zip\".\nThe \"Content-Range\" HTTP header shall be provided according to IETF RFC 7233.\n","headers":{"Content-Range":{"required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.\nThe \"Content-Type\" HTTP header shall be set according to the\ncontent type of the artifact file. If the content type cannot\nbe determined, the header shall be set to the value\n\"application/octet-stream\".\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualOnboardedVnfPackageArtifact.Get.200":{"description":"200 OK\n\nShall be returned when the whole content of the artifact file has\nbeen read successfully.\n\nIf the \"include_signatures\" request URI parameter was not provided in\nthe related request, the message content shall contain a copy of the artifact\nfile from the VNF package, as defined by ETSI GS NFV-SOL 004 and the \"Content-Type\"\nHTTP header shall be set according to the content type of the artifact file.\nIf the artifact is encrypted, the header shall be set to the value \"application/cms\"\n(IETF RFC 7193). If the content type cannot be determined, the header shall be set\nto the value \"application/octet-stream\".\n\nIf the \"include_signatures\" request URI parameter was provided in the related request,\nthe \"Content-Type\" HTTP header shall be set to \"application/zip and the message content\nshall contain a ZIP archive which includes:\n•\ta copy of the artifact file from the VNF package, as defined by ETSI GS NFV SOL 004;\n•\tthe related security information (individual signature file and optional related\n individual certificate file).\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.\nThe \"Content-Type\" HTTP header shall be set according to the\ncontent type of the artifact file. If the content type cannot\nbe determined, the header shall be set to the value\n\"application/octet-stream\".\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualOnboardedVnfPackageArtifact.Get.206":{"description":"206 PARTIAL CONTENT\n\nIf the NFVO supports range requests and the \"include_signatures\" request\nURI parameter was not present in the related request, this response shall\nbe returned when a single consecutive byte range from the content of the\nartifact file, if the NFVO supports range requests has been read successfully\naccording to the request.\nThe response body shall contain the requested part of the VNF\npackage file.\nThe \"Content-Range\" HTTP header shall be provided according to\nIETF RFC 7233.\nThe \"Content-Type\" HTTP header shall be set as defined above for\nthe \"200 OK\" response.\n","headers":{"Content-Range":{"required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"Subscriptions.Post.201":{"description":"201 CREATED\n\nShall be returned when the subscription has been created successfully.\nThe response body shall contain a representation of the created \"Individual subscription\" resource.\nThe HTTP response shall include a \"Location\" HTTP header that points to the created resource.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"The resource URI of the created PM Job","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a subscription related to notifications about VNF package management.\n","type":"object","required":["id","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications related to VNF package management.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE 1:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the \n notification types to facilitate automated code generation systems.\nNOTE 2:\tThe attributes \"vnfProductsFromProviders\", \"vnfdId\" and \"vnfPkgId\" are alternatives to reference to \n particular VNF packages in a filter. They should not be used both in the same filter instance, but \n one alternative should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfProductsFromProviders"]},{"required":["vnfdId"]},{"required":["vnfPkgId"]}]}],"properties":{"notificationTypes":{"description":"Match particular notification types. Permitted values: - VnfPackageOnboardingNotification - VnfPackageChangeNotification See note 1.\n","type":"array","items":{"type":"string","enum":["VnfPackageOnboardingNotification","VnfPackageChangeNotification"]}},"vnfProductsFromProviders":{"description":"If present, match VNF packages that contain VNF products from certain providers. See note 2.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF packages that contain VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"versions":{"description":"If present, match VNF packages that contain VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF packages that contain VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfdId":{"description":"Match VNF packages with a VNFD identifier listed in the attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfPkgId":{"description":"Match VNF packages with a package identifier listed in the attribute. May be present if the \"notificationTypes\" attribute contains the value \"VnfPackageChangeNotification\" and shall be absent otherwise. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"operationalState":{"description":"- ENABLED: The VNF package is enabled, i.e. it can be used for the creation of new \"Individual VNF instance\" resources.\n- DISABLED: The VNF package is disabled, i.e. it shall not be used for the creation of further \"Individual VNF instance\" resources\n (unless and until the VNF package is re-enabled).\n","type":"string","enum":["ENABLED","DISABLED"]},"usageState":{"description":"- IN_USE: \"Individual VNF instance\" resources created from this VNF package exist. - NOT_IN_USE: No \"Individual VNF instance\" resource created from this VNF package exists.\n","type":"string","enum":["IN_USE","NOT_IN_USE"]},"vnfmInfo":{"description":"Match strings that specify VNFMs compatible with the VNF. See table 10.5.2.2-1.\n","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"Subscriptions.Post.303":{"description":"303 See Other\n\nShall be returned when a subscription with the\nsame callback URI and the same filter already\nexists and the policy of the NFVO is to not create\nredundant subscriptions.\nThe HTTP response shall include a \"Location\"\nHTTP header that contains the resource URI of\nthe existing \"Individual subscription\" resource.\nThe response body shall be empty.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"The resource URI of the created PM Job","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"Subscriptions.Post.422":{"description":"422 Unprocessable Content\n\nShall be returned when a subscription with the\nsame callback URI and the same filter already\nexists and the policy of the NFVO is to not create\nredundant subscriptions.\nThe HTTP response shall include a \"Location\"\nHTTP header that contains the resource URI of\nthe existing \"Individual subscription\" resource.\nThe response body shall be empty.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"Subscriptions.Get.200":{"description":"200 OK\n\nShall be returned when the list of subscriptions has been queried successfully.\nThe response body shall contain in an array the representations of all active\nsubscriptions of the functional block that invokes the method, i.e. zero or more\nrepresentations of VNF package management subscriptions as defined in clause 10.5.2.4.\nIf the \"filter\" URI parameter was supplied in the request, the data in the response\nbody shall have been transformed according to the rules specified in clause 5.2.2\nof ETSI GS NFV-SOL 013\nIf the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013\nfor this resource, inclusion of the Link HTTP header in this response shall follow the provisions\nin clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a subscription related to notifications about VNF package management.\n","type":"object","required":["id","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications related to VNF package management.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE 1:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the \n notification types to facilitate automated code generation systems.\nNOTE 2:\tThe attributes \"vnfProductsFromProviders\", \"vnfdId\" and \"vnfPkgId\" are alternatives to reference to \n particular VNF packages in a filter. They should not be used both in the same filter instance, but \n one alternative should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfProductsFromProviders"]},{"required":["vnfdId"]},{"required":["vnfPkgId"]}]}],"properties":{"notificationTypes":{"description":"Match particular notification types. Permitted values: - VnfPackageOnboardingNotification - VnfPackageChangeNotification See note 1.\n","type":"array","items":{"type":"string","enum":["VnfPackageOnboardingNotification","VnfPackageChangeNotification"]}},"vnfProductsFromProviders":{"description":"If present, match VNF packages that contain VNF products from certain providers. See note 2.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF packages that contain VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"versions":{"description":"If present, match VNF packages that contain VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF packages that contain VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfdId":{"description":"Match VNF packages with a VNFD identifier listed in the attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfPkgId":{"description":"Match VNF packages with a package identifier listed in the attribute. May be present if the \"notificationTypes\" attribute contains the value \"VnfPackageChangeNotification\" and shall be absent otherwise. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"operationalState":{"description":"- ENABLED: The VNF package is enabled, i.e. it can be used for the creation of new \"Individual VNF instance\" resources.\n- DISABLED: The VNF package is disabled, i.e. it shall not be used for the creation of further \"Individual VNF instance\" resources\n (unless and until the VNF package is re-enabled).\n","type":"string","enum":["ENABLED","DISABLED"]},"usageState":{"description":"- IN_USE: \"Individual VNF instance\" resources created from this VNF package exist. - NOT_IN_USE: No \"Individual VNF instance\" resource created from this VNF package exists.\n","type":"string","enum":["IN_USE","NOT_IN_USE"]},"vnfmInfo":{"description":"Match strings that specify VNFMs compatible with the VNF. See table 10.5.2.2-1.\n","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"IndividualSubscription.Get.200":{"description":"200 OK\n\nShall be returned when information about an individual subscription has been read successfully.\nThe response body shall contain a representation of the \"Individual subscription\" resource.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a subscription related to notifications about VNF package management.\n","type":"object","required":["id","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications related to VNF package management.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE 1:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the \n notification types to facilitate automated code generation systems.\nNOTE 2:\tThe attributes \"vnfProductsFromProviders\", \"vnfdId\" and \"vnfPkgId\" are alternatives to reference to \n particular VNF packages in a filter. They should not be used both in the same filter instance, but \n one alternative should be chosen.\n","type":"object","anyOf":[{"oneOf":[{"required":["vnfProductsFromProviders"]},{"required":["vnfdId"]},{"required":["vnfPkgId"]}]}],"properties":{"notificationTypes":{"description":"Match particular notification types. Permitted values: - VnfPackageOnboardingNotification - VnfPackageChangeNotification See note 1.\n","type":"array","items":{"type":"string","enum":["VnfPackageOnboardingNotification","VnfPackageChangeNotification"]}},"vnfProductsFromProviders":{"description":"If present, match VNF packages that contain VNF products from certain providers. See note 2.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF packages that contain VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"versions":{"description":"If present, match VNF packages that contain VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"A version.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF packages that contain VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"A version.\n","type":"string"}}}}}}}}}}},"vnfdId":{"description":"Match VNF packages with a VNFD identifier listed in the attribute. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfPkgId":{"description":"Match VNF packages with a package identifier listed in the attribute. May be present if the \"notificationTypes\" attribute contains the value \"VnfPackageChangeNotification\" and shall be absent otherwise. See note 2.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"operationalState":{"description":"- ENABLED: The VNF package is enabled, i.e. it can be used for the creation of new \"Individual VNF instance\" resources.\n- DISABLED: The VNF package is disabled, i.e. it shall not be used for the creation of further \"Individual VNF instance\" resources\n (unless and until the VNF package is re-enabled).\n","type":"string","enum":["ENABLED","DISABLED"]},"usageState":{"description":"- IN_USE: \"Individual VNF instance\" resources created from this VNF package exist. - NOT_IN_USE: No \"Individual VNF instance\" resource created from this VNF package exists.\n","type":"string","enum":["IN_USE","NOT_IN_USE"]},"vnfmInfo":{"description":"Match strings that specify VNFMs compatible with the VNF. See table 10.5.2.2-1.\n","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualSubscription.Delete.204":{"description":"204 NO CONTENT\n\nShall be returned when the \"Individual subscription\" resource has been deleted successfully.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}}}}} diff --git a/v5.3.1/SOL003-VNFPackageManagement-API.yaml b/v5.3.1/SOL003-VNFPackageManagement-API.yaml new file mode 100644 index 00000000..8b009c67 --- /dev/null +++ b/v5.3.1/SOL003-VNFPackageManagement-API.yaml @@ -0,0 +1,21959 @@ +openapi: 3.0.2 +info: + title: SOL003 - VNF Package Management interface + description: | + SOL003 - VNF Package Management interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '2.12.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 003 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf +servers: + - url: 'http://127.0.0.1/vnfpkgm/v2' + - url: 'https://127.0.0.1/vnfpkgm/v2' +paths: + /api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /onboarded_vnf_packages: + get: + description: > + The GET method queries the information of the VNF packages matching the + filter. See clause 10.4.2.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - $ref: '#/components/parameters/filter_vnf_packages' + - name: all_fields + description: > + Include all complex attributes in the response. See clause 5.3 of + ETSI GS NFV-SOL 013 [8] for details. The NFVO shall support this + parameter. + in: query + required: false + schema: + type: string + - name: fields + description: > + Complex attributes to be included into the response. See clause 5.3 + of ETSI GS NFV-SOL 013 [8] for details. The NFVO should support this + parameter + in: query + required: false + schema: + type: string + - name: exclude_fields + description: > + Complex attributes to be excluded from the response. See clause 5.3 + of ETSI GS NFV-SOL 013 [8] for details. The NFVO should support this + parameter + in: query + required: false + schema: + type: string + - $ref: '#/components/parameters/exclude_default_vnf_packages' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the NFVO if the NFVO supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this + resource. + in: query + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/OnboardedVnfPackages.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /vnf_packages: + $ref: '#/paths/~1onboarded_vnf_packages' + '/vnf_packages/{vnfPkgId}': + parameters: + - $ref: '#/components/parameters/VnfPkgId' + get: + description: > + The GET method reads the information of an individual VNF package. + Clause 10.4.3.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualVnfPackage.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/onboarded_vnf_packages/{vnfdId}': + parameters: + - $ref: '#/components/parameters/VnfdId' + get: + description: > + The GET method reads the information of an individual VNF package. + Clause 10.4.3.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualOnboardedVnfPackage.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_packages/{vnfPkgId}/vnfd': + parameters: + - $ref: '#/components/parameters/VnfPkgId' + get: + description: > + The GET method reads the content of the VNFD within a VNF package. See + clause 10.4.4.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - $ref: '#/components/parameters/include_signatures_content_of_vnfd' + responses: + '200': + $ref: '#/components/responses/VnfdInIndividualVnfPackage.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/VnfdInIndividualVnfPackage.Get.409' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/onboarded_vnf_packages/{vnfdId}/vnfd': + parameters: + - $ref: '#/components/parameters/VnfdId' + get: + description: > + The GET method reads the content of the VNFD within a VNF package. See + clause 10.4.4.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - $ref: '#/components/parameters/include_signatures_content_of_vnfd' + responses: + '200': + $ref: '#/components/responses/VnfdInIndividualOnboardedVnfPackage.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/VnfdInIndividualOnboardedVnfPackage.Get.409' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_packages/{vnfPkgId}/manifest': + parameters: + - $ref: '#/components/parameters/VnfPkgId' + get: + description: > + The GET method reads the content of the manifest within a VNF package. + See clause 10.4.4a.3.1. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - $ref: '#/components/parameters/include_signatures_content_of_manifest' + responses: + '200': + $ref: '#/components/responses/ManifestInIndividualVnfPackage.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/ManifestInIndividualVnfPackage.Get.406' + '409': + $ref: '#/components/responses/ManifestInIndividualVnfPackage.Get.409' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/onboarded_vnf_packages/{vnfdId}/manifest': + parameters: + - $ref: '#/components/parameters/VnfdId' + get: + description: > + The GET method reads the content of the manifest within a VNF package. + See clause 10.4.4a.3.1. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - $ref: '#/components/parameters/include_signatures_content_of_manifest' + responses: + '200': + $ref: >- + #/components/responses/ManifestInIndividualOnboardedVnfPackage.Get.200 + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: >- + #/components/responses/ManifestInIndividualOnboardedVnfPackage.Get.406 + '409': + $ref: >- + #/components/responses/ManifestInIndividualOnboardedVnfPackage.Get.409 + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_packages/{vnfPkgId}/package_content': + parameters: + - $ref: '#/components/parameters/VnfPkgId' + get: + description: > + The GET method fetches the content of a VNF package identified by the + VNF package identifier allocated by the NFVO. + + See clause 10.4.5.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - $ref: '#/components/parameters/Range' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualVnfPackageContent.Get.200' + '206': + $ref: '#/components/responses/IndividualVnfPackageContent.Get.206' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/IndividualVnfPackageContent.Get.409' + '416': + $ref: '#/components/responses/IndividualVnfPackageContent.Get.416' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/onboarded_vnf_packages/{vnfdId}/package_content': + parameters: + - $ref: '#/components/parameters/VnfdId' + get: + description: > + The GET method fetches the content of a VNF package identified by the + VNF package identifier allocated by the NFVO. + + See clause 10.4.5.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - $ref: '#/components/parameters/Range' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualOnboardedVnfPackageContent.Get.200' + '206': + $ref: '#/components/responses/IndividualOnboardedVnfPackageContent.Get.206' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/IndividualOnboardedVnfPackageContent.Get.409' + '416': + $ref: '#/components/responses/IndividualOnboardedVnfPackageContent.Get.416' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_packages/{vnfPkgId}/artifacts': + parameters: + - $ref: '#/components/parameters/VnfPkgId' + get: + description: | + The GET method shall return an archive that contains a set of artifacts. + + This GET method is used to Bulk-fetch artifacts that are not images. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - $ref: '#/components/parameters/Range' + - $ref: '#/components/parameters/exclude_all_mano_artifacts' + - $ref: '#/components/parameters/exclude_all_non_mano_artifacts' + - $ref: '#/components/parameters/include_external_artifacts' + - $ref: '#/components/parameters/select_non_mano_artifact_sets' + - $ref: '#/components/parameters/include_signatures_artifacts' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualVnfPackageArtifacts.Get.200' + '206': + $ref: '#/components/responses/IndividualVnfPackageArtifacts.Get.206' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/IndividualVnfPackageArtifacts.Get.409' + '416': + $ref: '#/components/responses/IndividualVnfPackageArtifacts.Get.416' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/onboarded_vnf_packages/{vnfdId}/artifacts': + parameters: + - $ref: '#/components/parameters/VnfdId' + get: + description: | + The GET method fetches the content of an artifact within a VNF package. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - $ref: '#/components/parameters/Range' + - $ref: '#/components/parameters/exclude_all_mano_artifacts' + - $ref: '#/components/parameters/exclude_all_non_mano_artifacts' + - $ref: '#/components/parameters/include_external_artifacts' + - $ref: '#/components/parameters/select_non_mano_artifact_sets' + - $ref: '#/components/parameters/include_signatures_artifacts' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: >- + #/components/responses/IndividualOnboardedVnfPackageArtifacts.Get.200 + '206': + $ref: >- + #/components/responses/IndividualOnboardedVnfPackageArtifacts.Get.206 + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: >- + #/components/responses/IndividualOnboardedVnfPackageArtifacts.Get.409 + '416': + $ref: >- + #/components/responses/IndividualOnboardedVnfPackageArtifacts.Get.416 + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_packages/{vnfPkgId}/artifacts/{artifactPath}': + parameters: + - $ref: '#/components/parameters/ArtifactPath' + - $ref: '#/components/parameters/VnfPkgId' + get: + description: > + The GET method fetches the content of an artifact within a VNF package. + See clause 10.4.6.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - $ref: '#/components/parameters/Range' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - $ref: '#/components/parameters/include_signatures_content_of_artifact' + responses: + '200': + $ref: '#/components/responses/IndividualVnfPackageArtifact.Get.200' + '206': + $ref: '#/components/responses/IndividualVnfPackageArtifact.Get.206' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/IndividualVnfPackageArtifact.Get.409' + '416': + $ref: '#/components/responses/IndividualVnfPackageArtifact.Get.416' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/onboarded_vnf_packages/{vnfdId}/artifacts/{artifactPath}': + parameters: + - $ref: '#/components/parameters/ArtifactPath' + - $ref: '#/components/parameters/VnfdId' + get: + description: > + The GET method fetches the content of an artifact within a VNF package. + See clause 10.4.6.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - $ref: '#/components/parameters/Range' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - $ref: '#/components/parameters/include_signatures_content_of_artifact' + responses: + '200': + $ref: '#/components/responses/IndividualOnboardedVnfPackageArtifact.Get.200' + '206': + $ref: '#/components/responses/IndividualOnboardedVnfPackageArtifact.Get.206' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/IndividualOnboardedVnfPackageArtifact.Get.409' + '416': + $ref: '#/components/responses/IndividualOnboardedVnfPackageArtifact.Get.416' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /subscriptions: + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + post: + description: | + The POST method creates a new subscription. See clause 10.4.7.3.1. + requestBody: + $ref: '#/components/requestBodies/PkgmSubscriptionRequest' + responses: + '201': + $ref: '#/components/responses/Subscriptions.Post.201' + '303': + $ref: '#/components/responses/Subscriptions.Post.303' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/Subscriptions.Post.422' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + get: + description: > + The GET method queries the list of active subscriptions of the + functional block that invokes the method. + + It can be used e.g. for resynchronization after error situations. See + clause 10.4.7.3.2. + parameters: + - $ref: '#/components/parameters/filter_subscriptions' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the NFVO if the NFVO supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this + resource. + in: query + required: false + schema: + type: string + responses: + '200': + $ref: '#/components/responses/Subscriptions.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/subscriptions/{subscriptionId}': + parameters: + - $ref: '#/components/parameters/SubscriptionId' + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + get: + description: | + The GET method reads an individual subscription. See clause 10.4.8.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualSubscription.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + The DELETE method terminates an individual subscription. See clause + 10.4.8.3.5. + responses: + '204': + $ref: '#/components/responses/IndividualSubscription.Delete.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + parameters: + filter_vnf_packages: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013 [8]. The NFVO shall support receiving this parameter as part + of the URI query string. The VNFM may supply this parameter. All + attribute names that appear in the VnfPkgInfo and in data types + referenced from it shall be supported by the NFVO in the filter + expression. + in: query + required: false + schema: + type: string + exclude_default_vnf_packages: + name: exclude_default + in: query + description: >- + Indicates to exclude the following complex attributes from the response. + See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The NFVO shall + support this parameter. The following attributes shall be excluded from + the VnfPkgInfo structure in the response body if this parameter is + provided, or none of the parameters "all_fields," "fields", + "exclude_fields", "exclude_default" are provided: + - softwareImages + - additionalArtifacts + - userDefinedData + - checksum + - onboardingFailureDetails. + required: false + schema: + type: string + exclude_all_mano_artifacts: + name: exclude_all_mano_artifacts + description: > + Flag (i.e. parameter without value) that instructs the NFVO to exclude + the set of additional MANO artifacts (i.e. those that are not images) + from the response message content. The NFVO shall support this + parameter. The VNFM may supply this parameter. + in: query + required: false + schema: + type: string + exclude_all_non_mano_artifacts: + name: exclude_all_non_mano_artifacts + description: > + Flag (i.e. parameter without value) that instructs the NFVO to exclude + the set of non-MANO artifacts from the response message content. The + NFVO shall support this parameter. The VNFM may supply this parameter. + in: query + required: false + schema: + type: string + include_external_artifacts: + name: include_external_artifacts + description: > + Flag (i.e. parameter without value) that instructs the NFVO to include + external artifacts in the response message content. It shall not be + treated as an error if this flag is provided but there is no external + artifact to include in the result. If this parameter is missing, no + external artifacts shall be included. The NFVO shall support this + parameter. The VNFM may supply this parameter. + in: query + required: false + schema: + type: string + select_non_mano_artifact_sets: + name: select_non_mano_artifact_sets + description: > + Comma-separated list of non-MANO artifact set identifiers for which the + artifacts are to be included in the response body. The NFVO should + support this parameter. If the NFVO does not support this parameter, it + shall ignore it, i.e. provide a response as if no parameter was + provided. The VNFM may supply this parameter. + in: query + required: false + schema: + type: string + include_signatures_artifacts: + name: include_signatures + description: > + If this parameter is provided, the NFVO shall include in the ZIP archive + the individual signatures and, if provided, related certificates for the + included artifacts, in the format in which they are provided in the VNF + package. If this parameter is not given, the NFVO shall only provide + copies of the artifact files. This URI query parameter is a flag, i.e. + it shall have no value. The NFVO shall support this parameter. + in: query + required: false + schema: + type: string + include_signatures_content_of_artifact: + name: include_signatures + description: > + If this parameter is provided, the NFVO shall return the artifact and + related security information (such as signature and optional + certificate) in a ZIP archive. If this parameter is not given, the NFVO + shall provide only a copy of the artifact file. This URI query parameter + is a flag, i.e. it shall have no value. The NFVO shall support this + parameter. + in: query + required: false + schema: + type: string + filter_subscriptions: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013 [8]. The NFVO shall support receiving this parameter as part + of the URI query string. The VNFM may supply this parameter. All + attribute names that appear in the PkgmSubscription and in data types + referenced from it shall be supported by the NFVO in the filter + expression. + in: query + required: false + schema: + type: string + VnfPkgId: + name: vnfPkgId + in: path + description: | + Identifier of the VNF package. The identifier is allocated by the + NFVO. + This identifier can be retrieved from the "vnfPkgId" attribute in + the VnfPackageOnboardingNotification or + VnfPackageChangeNotification. + required: true + style: simple + explode: false + schema: + type: string + VnfdId: + name: vnfdId + in: path + description: | + Identifier of the VNFD and the VNF package. + The identifier is allocated by the VNF provider. + This identifier can be retrieved from the "vnfdId" attribute + in the VnfPackageOnboardingNotification or VnfPackageChangeNotification. + This identifier can be retrieved from the "vnfdId" attribute in the + VnfPackageOnboardingNotification or VnfPackageChangeNotification. + required: true + style: simple + explode: false + schema: + type: string + ArtifactPath: + name: artifactPath + in: path + description: > + SequenceFor an artifact contained as a file in the VNF package, + + this variable shall contain a sequence of one or more path segments + + representing the path of the artifact within the VNF package, + + relative to the root of the package. + + + EXAMPLE: foo/bar/m%40ster.sh + + + For an external artifact represented as a URI in the VNF package + + manifest, this variable shall contain a sequence of one or more path + + segments as synthesized by the NFVO (see clause 10.5.3.3), + + representing this artifact. + + + Since multiple path segments are allowed to be contained in this + variable, + + the "/" character that separates these segments is not percent-encoded. + + Each individual segment is percent-encoded if necessary as defined in + clause + + 4.1 of ETSI GS NFV-SOL 013. + required: true + style: simple + explode: false + schema: + type: string + SubscriptionId: + name: subscriptionId + in: path + description: > + Identifier of this subscription. + + This identifier can be retrieved from the resource referenced by + + the "Location" HTTP header in the response to a POST request + + creating a new "Individual subscription" resource. It can also be + retrieved from + + the "id" attribute in the message content of that response. + required: true + style: simple + explode: false + schema: + type: string + include_signatures_content_of_vnfd: + name: include_signatures + in: query + description: > + If this parameter is provided, the NFVO shall include in the ZIP archive + the security + + information as specified above. + + This URI query parameter is a flag, i.e. it shall have no value. + + The NFVO shall support this parameter. + required: false + schema: + type: string + include_signatures_content_of_manifest: + name: include_signatures + in: query + description: > + If this parameter is provided, the NFVO shall return the manifest and + related + + security information (such as certificate) in a ZIP archive. + + If this parameter is not given, the NFVO shall provide only a copy of + the manifest + + file. + + This URI query parameter is a flag, i.e. it shall have no value. + + The NFVO shall support this parameter. + required: false + schema: + type: string + Range: + name: Range + in: header + description: | + The request may contain a "Range" HTTP header to obtain single + range of bytes from the VNF package file. This can be used to + continue an aborted transmission. + + If the "Range" header is present in the request and the NFVO + does not support responding to range requests with a 206 response, + it shall return a 200 OK response instead. + required: false + schema: + type: string + requestBodies: + PkgmSubscriptionRequest: + description: | + Representation of the created subscription resource. + The HTTP response shall include a "Location" HTTP header that + points to the created subscription resource. + content: + application/json: + schema: + description: > + This type represents a subscription request related to VNF package + management notifications about VNF package on-boarding or changes. + type: object + required: + - callbackUri + properties: + filter: + description: "This type represents a subscription filter related to notifications related to VNF package management.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE 1:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the \n notification types to facilitate automated code generation systems.\nNOTE 2:\tThe attributes \"vnfProductsFromProviders\", \"vnfdId\" and \"vnfPkgId\" are alternatives to reference to \n particular VNF packages in a filter. They should not be used both in the same filter instance, but \n one alternative should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfProductsFromProviders + - required: + - vnfdId + - required: + - vnfPkgId + properties: + notificationTypes: + description: > + Match particular notification types. Permitted values: - + VnfPackageOnboardingNotification - + VnfPackageChangeNotification See note 1. + type: array + items: + type: string + enum: + - VnfPackageOnboardingNotification + - VnfPackageChangeNotification + vnfProductsFromProviders: + description: > + If present, match VNF packages that contain VNF products + from certain providers. See note 2. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + A string defined in IETF RFC 8259. + type: string + vnfProducts: + description: > + If present, match VNF packages that contain VNF + products with certain product names, from one + particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + A string defined in IETF RFC 8259. + type: string + versions: + description: > + If present, match VNF packages that contain + VNF products with certain versions and a + certain product name, from one particular + provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF packages that + contain VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfdId: + description: > + Match VNF packages with a VNFD identifier listed in the + attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfPkgId: + description: > + Match VNF packages with a package identifier listed in the + attribute. May be present if the "notificationTypes" + attribute contains the value + "VnfPackageChangeNotification" and shall be absent + otherwise. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + operationalState: + description: > + - ENABLED: The VNF package is enabled, i.e. it can be used + for + the creation of new "Individual VNF instance" resources. + - DISABLED: The VNF package is disabled, i.e. it shall not + be used for + the creation of further "Individual VNF instance" resources + (unless and until the VNF package is re-enabled). + type: string + enum: + - ENABLED + - DISABLED + usageState: + description: > + - IN_USE: "Individual VNF instance" resources created from + this VNF package exist. - NOT_IN_USE: No "Individual VNF + instance" resource created from this VNF package exists. + type: string + enum: + - IN_USE + - NOT_IN_USE + vnfmInfo: + description: > + Match strings that specify VNFMs compatible with the VNF. + See table 10.5.2.2-1. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + authentication: + description: > + * NOTE 1 : The clientId and clientPassword passed in a + subscription shall not be the same as the clientId and + clientPassword that are used to obtain authorization for API requests. Client credentials may differ between + subscriptions. The value of clientPassword should be generated by a random process. + * NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT + which uses mutual authentication based on X.509 + certificates, this mode which uses client password to authenticate may be used in the access token request + toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations + (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details. + * NOTE 3: The following values that were included up to + version 3.4.1 of the present document have been removed: + "BASIC" (to signal the use of the basic HTTP authentication) has been removed because it is insecure. + "TLS_CERT" to signal an alternative non-token based authorization method using TLS certificates has been + removed because the method is no longer supported. + * NOTE 4: The client certificate is established by means + outside the scope of the present document. + type: object + required: + - authType + properties: + authType: + description: > + Defines the types of Authentication / Authorization which + the API consumer is willing to accept when receiving a + notification. Permitted values (see note 3): * + OAUTH2_CLIENT_CREDENTIALS: In every + HTTP request to the notification endpoint, use + an OAuth 2.0 token, obtained using the client + credentials grant type after authenticating + using client identifier and client password + towards the token endpoint. + * OAUTH2_CLIENT_CERT: In every HTTP + request to the notification endpoint, use an + OAuth 2.0 token, obtained using the client + credentials grant type after mutually + authenticating using client identifier and X.509 + certificates towards the token endpoint. + type: array + items: + type: string + enum: + - OAUTH2_CLIENT_CREDENTIALS + - OAUTH2_CLIENT_CERT + paramsOauth2ClientCert: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CERT. + + Shall be present if authType is "OAUTH2_CLIENT_CERT" and + the contained information has not been provisioned out of + band. + + Shall be absent otherwise. + type: object + required: + - clientId + - certificateRef + - tokenEndpoint + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. + type: string + certificateRef: + description: > + Fingerprint of the client certificate. The hash + function shall use SHA256 or higher. See note 4. + type: string + required: + - type + - value + properties: + type: + description: | + A string defined in IETF RFC 8259. + type: string + value: + description: | + A string defined in IETF RFC 8259. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + paramsOauth2ClientCredentials: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CREDENTIALS. + + Shall be present if authType is + "OAUTH2_CLIENT_CREDENTIALS" and the contained information + has not been provisioned out of band. + + Shall be absent otherwise. + + See note 2. + type: object + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. Shall be present if it has not been + provisioned out of band. See note 1. + type: string + clientPassword: + description: > + Client password to be used in the access token request + of the OAuth 2.0 client credentials grant type. Shall + be present if it has not been provisioned out of band. + See note 1. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + responses: + OnboardedVnfPackages.Get.200: + description: > + 200 OK + + + Shall be returned when information about zero or more VNF packages has + been queried successfully. + + The response body shall contain in an array the VNF package info + representations that match the + + attribute filter, i.e. zero or more VNF package info representations as + defined in clause 10.5.2.2. + + If the "filter" URI parameter or one of the "all_fields", "fields" (if + supported), "exclude_fields" + + (if supported) or "exclude_default" URI parameters was supplied in the + request, the data in the + + response body shall have been transformed according to the rules + specified in clauses 5.2.2 and + + 5.3.2 of ETSI GS NFV-SOL 013, respectively. + + If the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 + of ETSI GS NFV-SOL 013 + + for this resource, inclusion of the Link HTTP header in this response + shall follow the provisions + + in clause 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: "This type represents the information of a VNF package.\nNOTE 1:\tIf the value of the onboardingState attribute is not equal to \"ONBOARDED\", the value of the operationalState \n attribute shall be equal to \"DISABLED\".\nNOTE 2:\tIf the value of the onboardingState attribute is not equal to \"ONBOARDED\", the value of the usageState attribute \n shall be equal to \"NOT_IN_USE\".\nNOTE 3:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n" + type: object + required: + - id + - onboardingState + - operationalState + - usageState + - vnfmInfo + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfdExtInvariantId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfProvider: + description: | + A string defined in IETF RFC 8259. + type: string + vnfProductName: + description: | + A string defined in IETF RFC 8259. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + compatibleSpecificationVersions: + description: > + Indicates which versions of the ETSI GS NFV-SOL 004 + specification the package complies to, as defined in the + manifest of the package. Each entry shall be formatted as + defined in clause 4.3.2 of ETSI GS NFV-SOL 004. + type: array + items: + description: | + A version. + type: string + checksum: + description: | + Cheksum description + type: string + packageSecurityOption: + description: > + Signals the security option used by the package as defined + in clause 5.1 of ETSI GS NFV-SOL 004. It shall be present + after the VNF package content has been on-boarded and absent + otherwise. Valid values: OPTION_1, OPTION_2 + type: string + enum: + - OPTION_1 + - OPTION_2 + signingCertificate: + description: | + A string defined in IETF RFC 8259. + type: string + softwareImages: + description: > + Information about VNF package artifacts that are software + images. This attribute shall not be present before the VNF + package content is on-boarded. Otherwise, this attribute + shall be present unless it has been requested to be excluded + per attribute selector. + type: array + items: + description: "This type represents an artifact contained in or external to a VNF package which represents a software image..\n* NOTE 1:\tThe list of permitted values was taken from \"Container formats\" in OpenStack® documentation: \"Disk and container formats for images\"\n (Available at https://docs.openstack.org/glance/pike/user/formats.html).\n* NOTE 2:\tThe list of permitted values was adapted from \"Disk formats\" in OpenStack® documentation: \"Disk and container formats for images\"\n (Available at https://docs.openstack.org/glance/pike/user/formats.html).\n* NOTE 3: The attribute shall be present for VM-based software images referenced from a Vdu, and shall be absent\n otherwise.\n* NOTE 4: The attribute shall be present for software images referenced from a VirtualStorageDesc, and shall be absent\n otherwise.\n" + type: object + required: + - id + - name + - provider + - version + - checksum + - isEncrypted + - containerFormat + - createdAt + - size + properties: + id: + description: | + An identifier that is unique within a VNF descriptor. + type: string + name: + description: | + A string defined in IETF RFC 8259. + type: string + provider: + description: | + A string defined in IETF RFC 8259. + type: string + version: + description: | + A version. + type: string + checksum: + description: | + Cheksum description + type: string + isEncrypted: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + containerFormat: + description: > + Container format indicates whether the software image + is in a file format that also contains metadata about + the actual software. Permitted values: - AKI: a kernel + image format - AMI: a machine image format - ARI: a + ramdisk image format - BARE: the image does not have a + container or metadata envelope - DOCKER: docker + container format - OVA: OVF package in a tarfile - + OVF: OVF container format See note 1. + type: string + enum: + - AKI + - AMI + - ARI + - BARE + - DOCKER + - OVA + - OVF + diskFormat: + description: > + Disk format of a software image is the format of the + underlying disk image. Permitted values: + - AKI: a kernel image format + - AMI: a machine image format + - ARI: a ramdisk image format + - ISO: an archive format for the data contents of an optical disc, + such as CD-ROM + - QCOW2: a common disk image format, which can expand dynamically + and supports copy on write + - RAW: an unstructured disk image format + - VDI: a common disk image format + - VHD: a common disk image format + - VHDX: enhanced version of VHD format + - VMDK: a common disk image format + See notes 2 and 3. + type: string + enum: + - AKI + - AMI + - ISO + - QCOW2 + - RAW + - VDI + - VHD + - VHDX + - VMDK + createdAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + minDisk: + description: > + The minimal disk for this software image in bytes. See + note 4. + type: integer + minRam: + description: > + The minimal RAM for this software image in bytes. See + note 3. + type: integer + size: + description: | + Size of this software image in bytes. + type: integer + userMetadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + imagePath: + description: > + Path which identifies the image artifact and also + allows to access a copy of the image artifact. For a + software image contained as a file in the VNF package, + this attribute shall be present, and the value of this + attribute shall start with the name of the first + segment in the path in the package, i.e., it shall not + be prefixed by path separator characters such as "." + and "/". EXAMPLE: foo/bar/m%40ster.vhd For an external + software image represented as a URI in the VNF + descriptor, this attribute shall be present if the + image artifact has been downloaded by the NFVO and + shall be absent otherwise. If present, it shall + contain the artifactPath under which the image + artifact can be obtained using the "Individual + artifact in a VNF package" resource defined in clause + 9.4.7. It is the responsibility of the NFVO to + synthesize this path in a manner that avoids any + collision of the synthesized artifact path with the + paths and names of image artifacts included in the + package. + type: string + imageUri: + description: | + String formatted according to IETF RFC 3986. + type: string + additionalArtifacts: + description: > + Information about VNF package artifacts contained in the VNF + package that are not software images. Every local and + external artifact declared in the manifest shall be + included, except the software images and the files that make + up the parts of the VNFD (see clause 10.4.4.3.2). Signature + files and certificate files are not considered as artifacts, + however, the content of the "Licenses" and "Testing" + directories in the VNF package is. This attribute shall not + be present before the VNF package content is on-boarded. + Otherwise, this attribute shall be present if the VNF + package contains additional artifacts. + type: array + items: + description: > + This type represents an artifact other than a software + image which is contained in or external to a VNF package. + + * NOTE: The attribute name "artifactURI" does not comply + with the naming convention defined in clause 4.3 in ETSI + GS NFV-SOL 015. This is to maintain the backward + compatibility. + type: object + required: + - artifactPath + - checksum + - isEncrypted + properties: + artifactPath: + description: | + A string defined in IETF RFC 8259. + type: string + artifactURI: + description: > + URI of the artifact as defined in the VNF package + manifest. Shall be present if the artifact is external + to the package and shall be absent otherwise. + EXAMPLE:https://example.com/m%40ster.sh See note. + type: array + items: + description: | + String formatted according to IETF RFC 3986. + type: string + checksum: + description: | + Cheksum description + type: string + isEncrypted: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + nonManoArtifactSetId: + description: | + A string defined in IETF RFC 8259. + type: string + artifactClassification: + description: "Marks specific types of artifacts as defined in the VNF package. If none of the specific classes listed below applies, the attribute shall not be present.\nValid values: -\tHISTORY: a history artifact as per clause 4.3.3 in ETSI GS NFV-SOL 004 -\tTESTING: a testing artifact as per clause 4.3.4 in ETSI GS NFV-SOL 004 -\tLICENSE: a license artifact as per clause 4.3.5 in ETSI GS NFV-SOL 004\n" + type: string + enum: + - HISTORY + - TESTING + - LICENSE + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + onboardingState: + description: > + CREATED: The "Individual VNF package" resource has been + created. UPLOADING: The associated VNF package content is + being uploaded. PROCESSING: The associated VNF package + content is being processed, e.g., + validation. + ONBOARDED: The associated VNF package content has been + on-boarded successfully. ERROR: There was an error during + upload of the VNF package content or external + artifacts, or during VNF package processing. + type: string + enum: + - CREATED + - UPLOADING + - PROCESSING + - ONBOARDED + - ERROR + operationalState: + description: > + - ENABLED: The VNF package is enabled, i.e. it can be used + for + the creation of new "Individual VNF instance" resources. + - DISABLED: The VNF package is disabled, i.e. it shall not + be used for + the creation of further "Individual VNF instance" resources + (unless and until the VNF package is re-enabled). + type: string + enum: + - ENABLED + - DISABLED + usageState: + description: > + - IN_USE: "Individual VNF instance" resources created from + this VNF package exist. - NOT_IN_USE: No "Individual VNF + instance" resource created from this VNF package exists. + type: string + enum: + - IN_USE + - NOT_IN_USE + vnfmInfo: + description: | + A string defined in IETF RFC 8259. + type: string + userDefinedData: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + onboardingFailureDetails: + description: > + The definition of the general "ProblemDetails" data + structure from IETF RFC 7807 is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807, + 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + - packageContent + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfd: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + packageContent: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualVnfPackage.Get.200: + description: > + 200 OK + + + Shall be returned when information of the VNF package has been read + successfully. + + The response body shall contain the VNF package info representation + defined in clause 10.5.2.2. + headers: + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: "This type represents the information of a VNF package.\nNOTE 1:\tIf the value of the onboardingState attribute is not equal to \"ONBOARDED\", the value of the operationalState \n attribute shall be equal to \"DISABLED\".\nNOTE 2:\tIf the value of the onboardingState attribute is not equal to \"ONBOARDED\", the value of the usageState attribute \n shall be equal to \"NOT_IN_USE\".\nNOTE 3:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n" + type: object + required: + - id + - onboardingState + - operationalState + - usageState + - vnfmInfo + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfdExtInvariantId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfProvider: + description: | + A string defined in IETF RFC 8259. + type: string + vnfProductName: + description: | + A string defined in IETF RFC 8259. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + compatibleSpecificationVersions: + description: > + Indicates which versions of the ETSI GS NFV-SOL 004 + specification the package complies to, as defined in the + manifest of the package. Each entry shall be formatted as + defined in clause 4.3.2 of ETSI GS NFV-SOL 004. + type: array + items: + description: | + A version. + type: string + checksum: + description: | + Cheksum description + type: string + packageSecurityOption: + description: > + Signals the security option used by the package as defined in + clause 5.1 of ETSI GS NFV-SOL 004. It shall be present after + the VNF package content has been on-boarded and absent + otherwise. Valid values: OPTION_1, OPTION_2 + type: string + enum: + - OPTION_1 + - OPTION_2 + signingCertificate: + description: | + A string defined in IETF RFC 8259. + type: string + softwareImages: + description: > + Information about VNF package artifacts that are software + images. This attribute shall not be present before the VNF + package content is on-boarded. Otherwise, this attribute shall + be present unless it has been requested to be excluded per + attribute selector. + type: array + items: + description: "This type represents an artifact contained in or external to a VNF package which represents a software image..\n* NOTE 1:\tThe list of permitted values was taken from \"Container formats\" in OpenStack® documentation: \"Disk and container formats for images\"\n (Available at https://docs.openstack.org/glance/pike/user/formats.html).\n* NOTE 2:\tThe list of permitted values was adapted from \"Disk formats\" in OpenStack® documentation: \"Disk and container formats for images\"\n (Available at https://docs.openstack.org/glance/pike/user/formats.html).\n* NOTE 3: The attribute shall be present for VM-based software images referenced from a Vdu, and shall be absent\n otherwise.\n* NOTE 4: The attribute shall be present for software images referenced from a VirtualStorageDesc, and shall be absent\n otherwise.\n" + type: object + required: + - id + - name + - provider + - version + - checksum + - isEncrypted + - containerFormat + - createdAt + - size + properties: + id: + description: | + An identifier that is unique within a VNF descriptor. + type: string + name: + description: | + A string defined in IETF RFC 8259. + type: string + provider: + description: | + A string defined in IETF RFC 8259. + type: string + version: + description: | + A version. + type: string + checksum: + description: | + Cheksum description + type: string + isEncrypted: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + containerFormat: + description: > + Container format indicates whether the software image is + in a file format that also contains metadata about the + actual software. Permitted values: - AKI: a kernel image + format - AMI: a machine image format - ARI: a ramdisk + image format - BARE: the image does not have a container + or metadata envelope - DOCKER: docker container format - + OVA: OVF package in a tarfile - OVF: OVF container + format See note 1. + type: string + enum: + - AKI + - AMI + - ARI + - BARE + - DOCKER + - OVA + - OVF + diskFormat: + description: > + Disk format of a software image is the format of the + underlying disk image. Permitted values: + - AKI: a kernel image format + - AMI: a machine image format + - ARI: a ramdisk image format + - ISO: an archive format for the data contents of an optical disc, + such as CD-ROM + - QCOW2: a common disk image format, which can expand dynamically + and supports copy on write + - RAW: an unstructured disk image format + - VDI: a common disk image format + - VHD: a common disk image format + - VHDX: enhanced version of VHD format + - VMDK: a common disk image format + See notes 2 and 3. + type: string + enum: + - AKI + - AMI + - ISO + - QCOW2 + - RAW + - VDI + - VHD + - VHDX + - VMDK + createdAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + minDisk: + description: > + The minimal disk for this software image in bytes. See + note 4. + type: integer + minRam: + description: > + The minimal RAM for this software image in bytes. See + note 3. + type: integer + size: + description: | + Size of this software image in bytes. + type: integer + userMetadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + imagePath: + description: > + Path which identifies the image artifact and also allows + to access a copy of the image artifact. For a software + image contained as a file in the VNF package, this + attribute shall be present, and the value of this + attribute shall start with the name of the first segment + in the path in the package, i.e., it shall not be + prefixed by path separator characters such as "." and + "/". EXAMPLE: foo/bar/m%40ster.vhd For an external + software image represented as a URI in the VNF + descriptor, this attribute shall be present if the + image artifact has been downloaded by the NFVO and shall + be absent otherwise. If present, it shall contain the + artifactPath under which the image artifact can be + obtained using the "Individual artifact in a VNF + package" resource defined in clause 9.4.7. It is the + responsibility of the NFVO to synthesize this path in a + manner that avoids any collision of the synthesized + artifact path with the paths and names of image + artifacts included in the package. + type: string + imageUri: + description: | + String formatted according to IETF RFC 3986. + type: string + additionalArtifacts: + description: > + Information about VNF package artifacts contained in the VNF + package that are not software images. Every local and external + artifact declared in the manifest shall be included, except + the software images and the files that make up the parts of + the VNFD (see clause 10.4.4.3.2). Signature files and + certificate files are not considered as artifacts, however, + the content of the "Licenses" and "Testing" directories in the + VNF package is. This attribute shall not be present before the + VNF package content is on-boarded. Otherwise, this attribute + shall be present if the VNF package contains additional + artifacts. + type: array + items: + description: > + This type represents an artifact other than a software image + which is contained in or external to a VNF package. + + * NOTE: The attribute name "artifactURI" does not comply + with the naming convention defined in clause 4.3 in ETSI GS + NFV-SOL 015. This is to maintain the backward compatibility. + type: object + required: + - artifactPath + - checksum + - isEncrypted + properties: + artifactPath: + description: | + A string defined in IETF RFC 8259. + type: string + artifactURI: + description: > + URI of the artifact as defined in the VNF package + manifest. Shall be present if the artifact is external + to the package and shall be absent otherwise. + EXAMPLE:https://example.com/m%40ster.sh See note. + type: array + items: + description: | + String formatted according to IETF RFC 3986. + type: string + checksum: + description: | + Cheksum description + type: string + isEncrypted: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + nonManoArtifactSetId: + description: | + A string defined in IETF RFC 8259. + type: string + artifactClassification: + description: "Marks specific types of artifacts as defined in the VNF package. If none of the specific classes listed below applies, the attribute shall not be present.\nValid values: -\tHISTORY: a history artifact as per clause 4.3.3 in ETSI GS NFV-SOL 004 -\tTESTING: a testing artifact as per clause 4.3.4 in ETSI GS NFV-SOL 004 -\tLICENSE: a license artifact as per clause 4.3.5 in ETSI GS NFV-SOL 004\n" + type: string + enum: + - HISTORY + - TESTING + - LICENSE + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + onboardingState: + description: > + CREATED: The "Individual VNF package" resource has been + created. UPLOADING: The associated VNF package content is + being uploaded. PROCESSING: The associated VNF package content + is being processed, e.g., + validation. + ONBOARDED: The associated VNF package content has been + on-boarded successfully. ERROR: There was an error during + upload of the VNF package content or external + artifacts, or during VNF package processing. + type: string + enum: + - CREATED + - UPLOADING + - PROCESSING + - ONBOARDED + - ERROR + operationalState: + description: > + - ENABLED: The VNF package is enabled, i.e. it can be used for + the creation of new "Individual VNF instance" resources. + - DISABLED: The VNF package is disabled, i.e. it shall not be + used for + the creation of further "Individual VNF instance" resources + (unless and until the VNF package is re-enabled). + type: string + enum: + - ENABLED + - DISABLED + usageState: + description: > + - IN_USE: "Individual VNF instance" resources created from + this VNF package exist. - NOT_IN_USE: No "Individual VNF + instance" resource created from this VNF package exists. + type: string + enum: + - IN_USE + - NOT_IN_USE + vnfmInfo: + description: | + A string defined in IETF RFC 8259. + type: string + userDefinedData: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + onboardingFailureDetails: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + - packageContent + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfd: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + packageContent: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualOnboardedVnfPackage.Get.200: + description: > + 200 OK + + + Shall be returned when information of the VNF package has been read + successfully. + + The response body shall contain the VNF package info representation + defined in clause 10.5.2.2. + headers: + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: "This type represents the information of a VNF package.\nNOTE 1:\tIf the value of the onboardingState attribute is not equal to \"ONBOARDED\", the value of the operationalState \n attribute shall be equal to \"DISABLED\".\nNOTE 2:\tIf the value of the onboardingState attribute is not equal to \"ONBOARDED\", the value of the usageState attribute \n shall be equal to \"NOT_IN_USE\".\nNOTE 3:\tETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n" + type: object + required: + - id + - onboardingState + - operationalState + - usageState + - vnfmInfo + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfdExtInvariantId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfProvider: + description: | + A string defined in IETF RFC 8259. + type: string + vnfProductName: + description: | + A string defined in IETF RFC 8259. + type: string + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersion: + description: | + A version. + type: string + compatibleSpecificationVersions: + description: > + Indicates which versions of the ETSI GS NFV-SOL 004 + specification the package complies to, as defined in the + manifest of the package. Each entry shall be formatted as + defined in clause 4.3.2 of ETSI GS NFV-SOL 004. + type: array + items: + description: | + A version. + type: string + checksum: + description: | + Cheksum description + type: string + packageSecurityOption: + description: > + Signals the security option used by the package as defined in + clause 5.1 of ETSI GS NFV-SOL 004. It shall be present after + the VNF package content has been on-boarded and absent + otherwise. Valid values: OPTION_1, OPTION_2 + type: string + enum: + - OPTION_1 + - OPTION_2 + signingCertificate: + description: | + A string defined in IETF RFC 8259. + type: string + softwareImages: + description: > + Information about VNF package artifacts that are software + images. This attribute shall not be present before the VNF + package content is on-boarded. Otherwise, this attribute shall + be present unless it has been requested to be excluded per + attribute selector. + type: array + items: + description: "This type represents an artifact contained in or external to a VNF package which represents a software image..\n* NOTE 1:\tThe list of permitted values was taken from \"Container formats\" in OpenStack® documentation: \"Disk and container formats for images\"\n (Available at https://docs.openstack.org/glance/pike/user/formats.html).\n* NOTE 2:\tThe list of permitted values was adapted from \"Disk formats\" in OpenStack® documentation: \"Disk and container formats for images\"\n (Available at https://docs.openstack.org/glance/pike/user/formats.html).\n* NOTE 3: The attribute shall be present for VM-based software images referenced from a Vdu, and shall be absent\n otherwise.\n* NOTE 4: The attribute shall be present for software images referenced from a VirtualStorageDesc, and shall be absent\n otherwise.\n" + type: object + required: + - id + - name + - provider + - version + - checksum + - isEncrypted + - containerFormat + - createdAt + - size + properties: + id: + description: | + An identifier that is unique within a VNF descriptor. + type: string + name: + description: | + A string defined in IETF RFC 8259. + type: string + provider: + description: | + A string defined in IETF RFC 8259. + type: string + version: + description: | + A version. + type: string + checksum: + description: | + Cheksum description + type: string + isEncrypted: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + containerFormat: + description: > + Container format indicates whether the software image is + in a file format that also contains metadata about the + actual software. Permitted values: - AKI: a kernel image + format - AMI: a machine image format - ARI: a ramdisk + image format - BARE: the image does not have a container + or metadata envelope - DOCKER: docker container format - + OVA: OVF package in a tarfile - OVF: OVF container + format See note 1. + type: string + enum: + - AKI + - AMI + - ARI + - BARE + - DOCKER + - OVA + - OVF + diskFormat: + description: > + Disk format of a software image is the format of the + underlying disk image. Permitted values: + - AKI: a kernel image format + - AMI: a machine image format + - ARI: a ramdisk image format + - ISO: an archive format for the data contents of an optical disc, + such as CD-ROM + - QCOW2: a common disk image format, which can expand dynamically + and supports copy on write + - RAW: an unstructured disk image format + - VDI: a common disk image format + - VHD: a common disk image format + - VHDX: enhanced version of VHD format + - VMDK: a common disk image format + See notes 2 and 3. + type: string + enum: + - AKI + - AMI + - ISO + - QCOW2 + - RAW + - VDI + - VHD + - VHDX + - VMDK + createdAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + minDisk: + description: > + The minimal disk for this software image in bytes. See + note 4. + type: integer + minRam: + description: > + The minimal RAM for this software image in bytes. See + note 3. + type: integer + size: + description: | + Size of this software image in bytes. + type: integer + userMetadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + imagePath: + description: > + Path which identifies the image artifact and also allows + to access a copy of the image artifact. For a software + image contained as a file in the VNF package, this + attribute shall be present, and the value of this + attribute shall start with the name of the first segment + in the path in the package, i.e., it shall not be + prefixed by path separator characters such as "." and + "/". EXAMPLE: foo/bar/m%40ster.vhd For an external + software image represented as a URI in the VNF + descriptor, this attribute shall be present if the + image artifact has been downloaded by the NFVO and shall + be absent otherwise. If present, it shall contain the + artifactPath under which the image artifact can be + obtained using the "Individual artifact in a VNF + package" resource defined in clause 9.4.7. It is the + responsibility of the NFVO to synthesize this path in a + manner that avoids any collision of the synthesized + artifact path with the paths and names of image + artifacts included in the package. + type: string + imageUri: + description: | + String formatted according to IETF RFC 3986. + type: string + additionalArtifacts: + description: > + Information about VNF package artifacts contained in the VNF + package that are not software images. Every local and external + artifact declared in the manifest shall be included, except + the software images and the files that make up the parts of + the VNFD (see clause 10.4.4.3.2). Signature files and + certificate files are not considered as artifacts, however, + the content of the "Licenses" and "Testing" directories in the + VNF package is. This attribute shall not be present before the + VNF package content is on-boarded. Otherwise, this attribute + shall be present if the VNF package contains additional + artifacts. + type: array + items: + description: > + This type represents an artifact other than a software image + which is contained in or external to a VNF package. + + * NOTE: The attribute name "artifactURI" does not comply + with the naming convention defined in clause 4.3 in ETSI GS + NFV-SOL 015. This is to maintain the backward compatibility. + type: object + required: + - artifactPath + - checksum + - isEncrypted + properties: + artifactPath: + description: | + A string defined in IETF RFC 8259. + type: string + artifactURI: + description: > + URI of the artifact as defined in the VNF package + manifest. Shall be present if the artifact is external + to the package and shall be absent otherwise. + EXAMPLE:https://example.com/m%40ster.sh See note. + type: array + items: + description: | + String formatted according to IETF RFC 3986. + type: string + checksum: + description: | + Cheksum description + type: string + isEncrypted: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + nonManoArtifactSetId: + description: | + A string defined in IETF RFC 8259. + type: string + artifactClassification: + description: "Marks specific types of artifacts as defined in the VNF package. If none of the specific classes listed below applies, the attribute shall not be present.\nValid values: -\tHISTORY: a history artifact as per clause 4.3.3 in ETSI GS NFV-SOL 004 -\tTESTING: a testing artifact as per clause 4.3.4 in ETSI GS NFV-SOL 004 -\tLICENSE: a license artifact as per clause 4.3.5 in ETSI GS NFV-SOL 004\n" + type: string + enum: + - HISTORY + - TESTING + - LICENSE + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + onboardingState: + description: > + CREATED: The "Individual VNF package" resource has been + created. UPLOADING: The associated VNF package content is + being uploaded. PROCESSING: The associated VNF package content + is being processed, e.g., + validation. + ONBOARDED: The associated VNF package content has been + on-boarded successfully. ERROR: There was an error during + upload of the VNF package content or external + artifacts, or during VNF package processing. + type: string + enum: + - CREATED + - UPLOADING + - PROCESSING + - ONBOARDED + - ERROR + operationalState: + description: > + - ENABLED: The VNF package is enabled, i.e. it can be used for + the creation of new "Individual VNF instance" resources. + - DISABLED: The VNF package is disabled, i.e. it shall not be + used for + the creation of further "Individual VNF instance" resources + (unless and until the VNF package is re-enabled). + type: string + enum: + - ENABLED + - DISABLED + usageState: + description: > + - IN_USE: "Individual VNF instance" resources created from + this VNF package exist. - NOT_IN_USE: No "Individual VNF + instance" resource created from this VNF package exists. + type: string + enum: + - IN_USE + - NOT_IN_USE + vnfmInfo: + description: | + A string defined in IETF RFC 8259. + type: string + userDefinedData: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + onboardingFailureDetails: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + - packageContent + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfd: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + packageContent: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + VnfdInIndividualVnfPackage.Get.200: + description: > + 200 OK + + + Shall be returned when the content of the VNFD has been read + successfully. + + The message content shall contain a copy of the file representing the + VNFD or + + a ZIP file that contains the file or multiple files representing the + VNFD, + + as specified above. + + The "Content-Type" HTTP header shall be set according to the format of + the + + returned file, i.e. to "text/plain" for a YAML file or to + "application/zip" + + for a ZIP file. + headers: + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + required: true + schema: + type: string + enum: + - text/plain + - application/zip + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + VnfdInIndividualVnfPackage.Get.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a conflict + with the state of the resource. + Typically, this is due to the fact that "onboardingState" + of the VNF package has a value different from + "ONBOARDED". + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + VnfdInIndividualOnboardedVnfPackage.Get.200: + description: > + 200 OK + + + Shall be returned when the content of the VNFD has been read + successfully. + + The message content shall contain a copy of the file representing the + VNFD or + + a ZIP file that contains the file or multiple files representing the + VNFD, + + as specified above. + + The "Content-Type" HTTP header shall be set according to the format of + the + + returned file, i.e. to "text/plain" for a YAML file or to + "application/zip" + + for a ZIP file. + headers: + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + required: true + schema: + type: string + enum: + - text/plain + - application/zip + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + VnfdInIndividualOnboardedVnfPackage.Get.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a conflict + with the state of the resource. + Typically, this is due to the fact that "onboardingState" + of the VNF package has a value different from + "ONBOARDED". + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + ManifestInIndividualVnfPackage.Get.200: + description: "200 OK\n\nShall be returned when the content of the manifest has been read successfully.\nIf the \"include_signatures\" URI query parameter was absent in the request,\nor if the manifest file has all security-related information embedded\n(i.e. there is no separate certificate file), the message content shall contain\na copy of the manifest file of the VNF package and the \"Content-Type\" HTTP\nheader shall be set to \"text/plain\".\n\nIf the \"include_signatures\" URI query parameter was present in the related\nrequest and the manifest file does not have all the security-related\ninformation embedded (i.e. there is a separate certificate file),\nthe \"Content-Type\" HTTP header shall be set to \"application/zip and the\nmessage content shall contain a ZIP archive which includes:\n•\ta copy of the manifest file of the VNF package;\n•\ta copy of the related individual certificate file.\n" + headers: + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + required: true + schema: + type: string + enum: + - text/plain + - application/zip + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + ManifestInIndividualVnfPackage.Get.406: + description: | + 406 Not Acceptable + + If the related request contained an "Accept" header + not compatible with the Content type "application/zip" + but the "include_signatures" flag was provided, the + NFVO shall respond with this response code. + The "ProblemDetails" structure may be included with + the "detail" attribute providing more information about + the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + ManifestInIndividualVnfPackage.Get.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that "onboardingState" + of the VNF package has a value different from + "ONBOARDED". + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + ManifestInIndividualOnboardedVnfPackage.Get.200: + description: "200 OK\n\nShall be returned when the content of the manifest has been read successfully.\nIf the \"include_signatures\" URI query parameter was absent in the request,\nor if the manifest file has all security-related information embedded\n(i.e. there is no separate certificate file), the message content shall contain\na copy of the manifest file of the VNF package and the \"Content-Type\" HTTP\nheader shall be set to \"text/plain\".\n\nIf the \"include_signatures\" URI query parameter was present in the related\nrequest and the manifest file does not have all the security-related\ninformation embedded (i.e. there is a separate certificate file),\nthe \"Content-Type\" HTTP header shall be set to \"application/zip and the\nmessage content shall contain a ZIP archive which includes:\n•\ta copy of the manifest file of the VNF package;\n•\ta copy of the related individual certificate file.\n" + headers: + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + required: true + schema: + type: string + enum: + - text/plain + - application/zip + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + ManifestInIndividualOnboardedVnfPackage.Get.406: + description: | + 406 Not Acceptable + + If the related request contained an "Accept" header + not compatible with the Content type "application/zip" + but the "include_signatures" flag was provided, the + NFVO shall respond with this response code. + The "ProblemDetails" structure may be included with + the "detail" attribute providing more information about + the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + ManifestInIndividualOnboardedVnfPackage.Get.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that "onboardingState" + of the VNF package has a value different from + "ONBOARDED". + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualVnfPackageContent.Get.200: + description: > + 200 OK + + + Shall be returned when the whole content of the VNF package file has + been read successfully. + + The response body shall include a copy of the VNF package file. + + The "Content-Type HTTP" header shall be set according to the type of the + file, + + i.e. to "application/zip" for a VNF Package as defined in ETSI GS NFV + SOL 004. + headers: + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualVnfPackageContent.Get.206: + description: > + 206 PARTIAL CONTENT + + + If the NFVO supports range requests, this response shall be returned + when + + a single consecutive byte range from the content of the VNF package file + + has been read successfully according to the request. + + The response body shall contain the requested part of the VNF package + file. + + The "Content-Range" HTTP header shall be provided according to IETF RFC + 9110 [16]. + + The "Content-Type" HTTP header shall be set as defined above for the + "200 OK" response. + headers: + Content-Range: + required: true + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualVnfPackageContent.Get.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that + "onboardingState" of the VNF package has a value + different from "ONBOARDED". + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualVnfPackageContent.Get.416: + description: | + 416 Range Not Satisfiable + + Shall be returned upon the following error: The byte + range passed in the "Range" header did not match + any available byte range in the VNF package file + (e.g. "access after end of file"). + The response body may contain a ProblemDetails + structure + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualOnboardedVnfPackageContent.Get.200: + description: > + 200 OK + + + Shall be returned when the whole content of the VNF package file has + been read successfully. + + The response body shall include a copy of the VNF package file. + + The "Content-Type HTTP" header shall be set according to the type of the + file, + + i.e. to "application/zip" for a VNF Package as defined in ETSI GS NFV + SOL 004. + headers: + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualOnboardedVnfPackageContent.Get.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that + "onboardingState" of the VNF package has a value + different from "ONBOARDED". + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualOnboardedVnfPackageContent.Get.416: + description: | + 416 Range Not Satisfiable + + Shall be returned upon the following error: The byte + range passed in the "Range" header did not match + any available byte range in the VNF package file + (e.g. "access after end of file"). + The response body may contain a ProblemDetails + structure + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + IndividualVnfPackageArtifact.Get.200: + description: "200 OK\n\nShall be returned when the whole content of the artifact file has\nbeen read successfully.\n\nIf the \"include_signatures\" request URI parameter was not provided in\nthe related request, the message content shall contain a copy of the artifact\nfile from the VNF package, as defined by ETSI GS NFV-SOL 004 and the \"Content-Type\"\nHTTP header shall be set according to the content type of the artifact file.\nIf the artifact is encrypted, the header shall be set to the value \"application/cms\"\n(IETF RFC 7193). If the content type cannot be determined, the header shall be set\nto the value \"application/octet-stream\".\n\nIf the \"include_signatures\" request URI parameter was provided in the related request,\nthe \"Content-Type\" HTTP header shall be set to \"application/zip and the message content\nshall contain a ZIP archive which includes:\n•\ta copy of the artifact file from the VNF package, as defined by ETSI GS NFV SOL 004;\n•\tthe related security information (individual signature file and optional related\n individual certificate file).\n" + headers: + Content-Type: + description: | + The MIME type of the body of the response. + The "Content-Type" HTTP header shall be set according to the + content type of the artifact file. If the content type cannot + be determined, the header shall be set to the value + "application/octet-stream". + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualVnfPackageArtifact.Get.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that + "onboardingState" of the VNF package has a value + different from "ONBOARDED". + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualVnfPackageArtifact.Get.416: + description: | + 416 Range Not Satisfiable + + Shall be returned upon the following error: The byte + range passed in the "Range" header did not match + any available byte range in the artifact file + (e.g. "access after end of file"). + The response body may contain a ProblemDetails + structure + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualOnboardedVnfPackageArtifact.Get.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that + "onboardingState" of the VNF package has a value + different from "ONBOARDED". + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualOnboardedVnfPackageArtifact.Get.416: + description: | + 416 Range Not Satisfiable + + Shall be returned upon the following error: The byte + range passed in the "Range" header did not match + any available byte range in the artifact file + (e.g. "access after end of file"). + The response body may contain a ProblemDetails + structure + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualVnfPackageArtifacts.Get.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that + "onboardingState" of the VNF package has a value + different from "ONBOARDED". + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualVnfPackageArtifacts.Get.416: + description: | + 416 Range Not Satisfiable + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that + "onboardingState" of the VNF package has a value + different from "ONBOARDED". + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualOnboardedVnfPackageArtifacts.Get.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that + "onboardingState" of the VNF package has a value + different from "ONBOARDED". + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualOnboardedVnfPackageArtifacts.Get.416: + description: | + 416 Range Not Satisfiable + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact that + "onboardingState" of the VNF package has a value + different from "ONBOARDED". + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualOnboardedVnfPackageContent.Get.206: + description: > + 206 PARTIAL CONTENT + + + If the NFVO supports range requests, this response shall be returned + when + + a single consecutive byte range from the content of the VNF package file + + has been read successfully according to the request. + + The response body shall contain the requested part of the VNF package + file. + + The "Content-Range" HTTP header shall be provided according to IETF RFC + 9110 [16]. + + The "Content-Type" HTTP header shall be set as defined above for the + "200 OK" response. + headers: + Content-Range: + required: true + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + required: true + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualVnfPackageArtifacts.Get.200: + description: | + 200 OK + + Shall be returned when the whole content of the archive containing + the artifact files has been read successfully. + The message content shall be a ZIP archive containing the requested + set of artifacts selected according to the provisions specified above + in this clause, and, if the flag "include_signatures" was provided in + the related request, the applicable signature files and, if available, + the separate certificate files from the VNF package. + The "Content-Type" HTTP header shall be set to "application/zip". + headers: + Content-Type: + description: | + The MIME type of the body of the response. + The "Content-Type" HTTP header shall be set according to the + content type of the artifact file. If the content type cannot + be determined, the header shall be set to the value + "application/octet-stream". + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualVnfPackageArtifact.Get.206: + description: > + 206 PARTIAL CONTENT + + + If the NFVO supports range requests and the "include_signatures" request + + URI parameter was not present in the related request, this response + shall + + be returned when a single consecutive byte range from the content of the + + artifact file, if the NFVO supports range requests has been read + successfully + + according to the request. + + The response body shall contain the requested part of the VNF + + package file. + + The "Content-Range" HTTP header shall be provided according to + + IETF RFC 9110 [18]. + + The "Content-Type" HTTP header shall be set as defined above for + + the "200 OK" response. + headers: + Content-Range: + required: true + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + required: true + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualVnfPackageArtifacts.Get.206: + description: > + 206 PARTIAL CONTENT + + + If the NFVO supports range requests, this response shall be returned + + when a single consecutive byte range from the content of the archive + + that would have been returned in a "200 OK" response has been read + + successfully according to the request. + + The response body shall contain the requested part of the archive. + + The "Content-Type" HTTP header shall be set to "application/zip". + + The "Content-Range" HTTP header shall be provided according to IETF RFC + 9110 [17]. + headers: + Content-Range: + required: true + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. + The "Content-Type" HTTP header shall be set according to the + content type of the artifact file. If the content type cannot + be determined, the header shall be set to the value + "application/octet-stream". + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualOnboardedVnfPackageArtifacts.Get.200: + description: | + 200 OK + + Shall be returned when the whole content of the archive containing + the artifact files has been read successfully. + The message content shall be a ZIP archive containing the requested + set of artifacts selected according to the provisions specified above + in this clause, and, if the flag "include_signatures" was provided in + the related request, the applicable signature files and, if available, + the separate certificate files from the VNF package. + The "Content-Type" HTTP header shall be set to "application/zip". + headers: + Content-Type: + description: | + The MIME type of the body of the response. + The "Content-Type" HTTP header shall be set according to the + content type of the artifact file. If the content type cannot + be determined, the header shall be set to the value + "application/octet-stream". + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualOnboardedVnfPackageArtifacts.Get.206: + description: > + 206 PARTIAL CONTENT + + + If the NFVO supports range requests, this response shall be returned + + when a single consecutive byte range from the content of the archive + + that would have been returned in a "200 OK" response has been read + + successfully according to the request. + + The response body shall contain the requested part of the archive. + + The "Content-Type" HTTP header shall be set to "application/zip". + + The "Content-Range" HTTP header shall be provided according to IETF RFC + 7233. + headers: + Content-Range: + required: true + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. + The "Content-Type" HTTP header shall be set according to the + content type of the artifact file. If the content type cannot + be determined, the header shall be set to the value + "application/octet-stream". + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualOnboardedVnfPackageArtifact.Get.200: + description: "200 OK\n\nShall be returned when the whole content of the artifact file has\nbeen read successfully.\n\nIf the \"include_signatures\" request URI parameter was not provided in\nthe related request, the message content shall contain a copy of the artifact\nfile from the VNF package, as defined by ETSI GS NFV-SOL 004 and the \"Content-Type\"\nHTTP header shall be set according to the content type of the artifact file.\nIf the artifact is encrypted, the header shall be set to the value \"application/cms\"\n(IETF RFC 7193). If the content type cannot be determined, the header shall be set\nto the value \"application/octet-stream\".\n\nIf the \"include_signatures\" request URI parameter was provided in the related request,\nthe \"Content-Type\" HTTP header shall be set to \"application/zip and the message content\nshall contain a ZIP archive which includes:\n•\ta copy of the artifact file from the VNF package, as defined by ETSI GS NFV SOL 004;\n•\tthe related security information (individual signature file and optional related\n individual certificate file).\n" + headers: + Content-Type: + description: | + The MIME type of the body of the response. + The "Content-Type" HTTP header shall be set according to the + content type of the artifact file. If the content type cannot + be determined, the header shall be set to the value + "application/octet-stream". + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualOnboardedVnfPackageArtifact.Get.206: + description: > + 206 PARTIAL CONTENT + + + If the NFVO supports range requests and the "include_signatures" request + + URI parameter was not present in the related request, this response + shall + + be returned when a single consecutive byte range from the content of the + + artifact file, if the NFVO supports range requests has been read + successfully + + according to the request. + + The response body shall contain the requested part of the VNF + + package file. + + The "Content-Range" HTTP header shall be provided according to + + IETF RFC 7233. + + The "Content-Type" HTTP header shall be set as defined above for + + the "200 OK" response. + headers: + Content-Range: + required: true + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Subscriptions.Post.201: + description: > + 201 CREATED + + + Shall be returned when the subscription has been created successfully. + + The response body shall contain a representation of the created + "Individual subscription" resource. + + The HTTP response shall include a "Location" HTTP header that points to + the created resource. + headers: + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: The resource URI of the created PM Job + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: > + This type represents a subscription related to notifications + about VNF package management. + type: object + required: + - id + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: "This type represents a subscription filter related to notifications related to VNF package management.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE 1:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the \n notification types to facilitate automated code generation systems.\nNOTE 2:\tThe attributes \"vnfProductsFromProviders\", \"vnfdId\" and \"vnfPkgId\" are alternatives to reference to \n particular VNF packages in a filter. They should not be used both in the same filter instance, but \n one alternative should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfProductsFromProviders + - required: + - vnfdId + - required: + - vnfPkgId + properties: + notificationTypes: + description: > + Match particular notification types. Permitted values: - + VnfPackageOnboardingNotification - + VnfPackageChangeNotification See note 1. + type: array + items: + type: string + enum: + - VnfPackageOnboardingNotification + - VnfPackageChangeNotification + vnfProductsFromProviders: + description: > + If present, match VNF packages that contain VNF products + from certain providers. See note 2. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + A string defined in IETF RFC 8259. + type: string + vnfProducts: + description: > + If present, match VNF packages that contain VNF + products with certain product names, from one + particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + A string defined in IETF RFC 8259. + type: string + versions: + description: > + If present, match VNF packages that contain + VNF products with certain versions and a + certain product name, from one particular + provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF packages that + contain VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfdId: + description: > + Match VNF packages with a VNFD identifier listed in the + attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfPkgId: + description: > + Match VNF packages with a package identifier listed in + the attribute. May be present if the "notificationTypes" + attribute contains the value + "VnfPackageChangeNotification" and shall be absent + otherwise. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + operationalState: + description: > + - ENABLED: The VNF package is enabled, i.e. it can be + used for + the creation of new "Individual VNF instance" resources. + - DISABLED: The VNF package is disabled, i.e. it shall + not be used for + the creation of further "Individual VNF instance" resources + (unless and until the VNF package is re-enabled). + type: string + enum: + - ENABLED + - DISABLED + usageState: + description: > + - IN_USE: "Individual VNF instance" resources created + from this VNF package exist. - NOT_IN_USE: No + "Individual VNF instance" resource created from this VNF + package exists. + type: string + enum: + - IN_USE + - NOT_IN_USE + vnfmInfo: + description: > + Match strings that specify VNFMs compatible with the + VNF. See table 10.5.2.2-1. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + Subscriptions.Post.303: + description: | + 303 See Other + + Shall be returned when a subscription with the + same callback URI and the same filter already + exists and the policy of the NFVO is to not create + redundant subscriptions. + The HTTP response shall include a "Location" + HTTP header that contains the resource URI of + the existing "Individual subscription" resource. + The response body shall be empty. + headers: + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: The resource URI of the created PM Job + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Subscriptions.Post.422: + description: | + 422 Unprocessable Content + + Shall be returned when a subscription with the + same callback URI and the same filter already + exists and the policy of the NFVO is to not create + redundant subscriptions. + The HTTP response shall include a "Location" + HTTP header that contains the resource URI of + the existing "Individual subscription" resource. + The response body shall be empty. + headers: + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + Subscriptions.Get.200: + description: > + 200 OK + + + Shall be returned when the list of subscriptions has been queried + successfully. + + The response body shall contain in an array the representations of all + active + + subscriptions of the functional block that invokes the method, i.e. zero + or more + + representations of VNF package management subscriptions as defined in + clause 10.5.2.4. + + If the "filter" URI parameter was supplied in the request, the data in + the response + + body shall have been transformed according to the rules specified in + clause 5.2.2 + + of ETSI GS NFV-SOL 013 + + If the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 + of ETSI GS NFV-SOL 013 + + for this resource, inclusion of the Link HTTP header in this response + shall follow the provisions + + in clause 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: > + This type represents a subscription related to notifications + about VNF package management. + type: object + required: + - id + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: "This type represents a subscription filter related to notifications related to VNF package management.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE 1:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the \n notification types to facilitate automated code generation systems.\nNOTE 2:\tThe attributes \"vnfProductsFromProviders\", \"vnfdId\" and \"vnfPkgId\" are alternatives to reference to \n particular VNF packages in a filter. They should not be used both in the same filter instance, but \n one alternative should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfProductsFromProviders + - required: + - vnfdId + - required: + - vnfPkgId + properties: + notificationTypes: + description: > + Match particular notification types. Permitted values: - + VnfPackageOnboardingNotification - + VnfPackageChangeNotification See note 1. + type: array + items: + type: string + enum: + - VnfPackageOnboardingNotification + - VnfPackageChangeNotification + vnfProductsFromProviders: + description: > + If present, match VNF packages that contain VNF products + from certain providers. See note 2. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + A string defined in IETF RFC 8259. + type: string + vnfProducts: + description: > + If present, match VNF packages that contain VNF + products with certain product names, from one + particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + A string defined in IETF RFC 8259. + type: string + versions: + description: > + If present, match VNF packages that contain + VNF products with certain versions and a + certain product name, from one particular + provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF packages that + contain VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfdId: + description: > + Match VNF packages with a VNFD identifier listed in the + attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfPkgId: + description: > + Match VNF packages with a package identifier listed in + the attribute. May be present if the "notificationTypes" + attribute contains the value + "VnfPackageChangeNotification" and shall be absent + otherwise. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + operationalState: + description: > + - ENABLED: The VNF package is enabled, i.e. it can be + used for + the creation of new "Individual VNF instance" resources. + - DISABLED: The VNF package is disabled, i.e. it shall + not be used for + the creation of further "Individual VNF instance" resources + (unless and until the VNF package is re-enabled). + type: string + enum: + - ENABLED + - DISABLED + usageState: + description: > + - IN_USE: "Individual VNF instance" resources created + from this VNF package exist. - NOT_IN_USE: No + "Individual VNF instance" resource created from this VNF + package exists. + type: string + enum: + - IN_USE + - NOT_IN_USE + vnfmInfo: + description: > + Match strings that specify VNFMs compatible with the + VNF. See table 10.5.2.2-1. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualSubscription.Get.200: + description: > + 200 OK + + + Shall be returned when information about an individual subscription has + been read successfully. + + The response body shall contain a representation of the "Individual + subscription" resource. + headers: + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + This type represents a subscription related to notifications about + VNF package management. + type: object + required: + - id + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: "This type represents a subscription filter related to notifications related to VNF package management.\nAt a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\nNOTE 1:\tThe permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the \n notification types to facilitate automated code generation systems.\nNOTE 2:\tThe attributes \"vnfProductsFromProviders\", \"vnfdId\" and \"vnfPkgId\" are alternatives to reference to \n particular VNF packages in a filter. They should not be used both in the same filter instance, but \n one alternative should be chosen.\n" + type: object + anyOf: + - oneOf: + - required: + - vnfProductsFromProviders + - required: + - vnfdId + - required: + - vnfPkgId + properties: + notificationTypes: + description: > + Match particular notification types. Permitted values: - + VnfPackageOnboardingNotification - + VnfPackageChangeNotification See note 1. + type: array + items: + type: string + enum: + - VnfPackageOnboardingNotification + - VnfPackageChangeNotification + vnfProductsFromProviders: + description: > + If present, match VNF packages that contain VNF products + from certain providers. See note 2. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + A string defined in IETF RFC 8259. + type: string + vnfProducts: + description: > + If present, match VNF packages that contain VNF + products with certain product names, from one + particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + A string defined in IETF RFC 8259. + type: string + versions: + description: > + If present, match VNF packages that contain + VNF products with certain versions and a + certain product name, from one particular + provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF packages that + contain VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfdId: + description: > + Match VNF packages with a VNFD identifier listed in the + attribute. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfPkgId: + description: > + Match VNF packages with a package identifier listed in the + attribute. May be present if the "notificationTypes" + attribute contains the value + "VnfPackageChangeNotification" and shall be absent + otherwise. See note 2. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + operationalState: + description: > + - ENABLED: The VNF package is enabled, i.e. it can be used + for + the creation of new "Individual VNF instance" resources. + - DISABLED: The VNF package is disabled, i.e. it shall not + be used for + the creation of further "Individual VNF instance" resources + (unless and until the VNF package is re-enabled). + type: string + enum: + - ENABLED + - DISABLED + usageState: + description: > + - IN_USE: "Individual VNF instance" resources created from + this VNF package exist. - NOT_IN_USE: No "Individual VNF + instance" resource created from this VNF package exists. + type: string + enum: + - IN_USE + - NOT_IN_USE + vnfmInfo: + description: > + Match strings that specify VNFMs compatible with the VNF. + See table 10.5.2.2-1. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualSubscription.Delete.204: + description: > + 204 NO CONTENT + + + Shall be returned when the "Individual subscription" resource has been + deleted successfully. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + diff --git a/v5.3.1/SOL003-VNFPackageManagementNotification-API.json b/v5.3.1/SOL003-VNFPackageManagementNotification-API.json new file mode 100644 index 00000000..a6060c6a --- /dev/null +++ b/v5.3.1/SOL003-VNFPackageManagementNotification-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL003 - VNF Package Management Notification interface","description":"SOL003 - VNF Package Management Notification interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"2.12.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 003 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/callback/v2"},{"url":"https://127.0.0.1/callback/v2"}],"paths":{"/URI_is_provided_by_the_client_when_creating_the_subscription-VnfPackageOnboardingNotification":{"parameters":[{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"post":{"description":"The POST method delivers a notification from the API producer to an API consumer.\nThe API consumer shall have previously created an \"Individual subscription\" resource with a matching filter.\nSee clause 10.4.9.3.1.\n","parameters":[{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/VnfPackageOnboardingNotification"},"responses":{"204":{"$ref":"#/components/responses/VnfPackageOnboardingNotification.Post.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"get":{"description":"The GET method allows the API producer to test the notification endpoint that is provided by the API consumer,\ne.g. during subscription. See clause 10.4.9.3.2.\n","responses":{"204":{"$ref":"#/components/responses/VnfPackageOnboardingNotification.Get.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/URI_is_provided_by_the_client_when_creating_the_subscription-VnfPackageChangeNotification":{"parameters":[{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"post":{"description":"The POST method delivers a notification from the API producer to an API consumer.\nThe API consumer shall have previously created an \"Individual subscription\" resource with a matching filter.\nSee clause 10.4.9.3.1.\n","parameters":[{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/VnfPackageChangeNotification"},"responses":{"204":{"$ref":"#/components/responses/VnfPackageChangeNotification.Post.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"get":{"description":"The GET method allows the API producer to test the notification endpoint that is provided by the API consumer,\ne.g. during subscription. See clause 10.4.9.3.2.\n","responses":{"204":{"$ref":"#/components/responses/VnfPackageChangeNotification.Get.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"requestBodies":{"VnfPackageOnboardingNotification":{"description":"A notification about on-boarding of a VNF package.","content":{"application/json":{"schema":{"description":"This type represents a VNF package management notification, which informs the receiver that the onboarding process of a VNF package is complete and the package is ready for use. The notification shall be triggered by the NFVO when the \"onboardingState\" attribute of a new VNF package has changed to \"ONBOARDED\".\n","type":"object","required":["id","notificationType","subscriptionId","timeStamp","vnfPkgId","vnfdId","vnfmInfo","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"VnfPackageOnboardingNotification\" for this notification type.\n","type":"string","enum":["VnfPackageOnboardingNotification"]},"subscriptionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfPkgId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfmInfo":{"description":"Specifies VNFMs compatible with the VNF. This information is copied from the VNFD. See table 10.5.2.2-1.\n","type":"array","items":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}},"_links":{"description":"This type represents the links to resources that a VNF package management notification can contain.\n","type":"object","required":["vnfPackage","subscription"],"properties":{"vnfPackage":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfPackageByVnfdId":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"subscription":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true},"VnfPackageChangeNotification":{"description":"A notification about changes of status in a VNF package.=\n","content":{"application/json":{"schema":{"description":"This type represents a VNF package management notification, which informs the receiver of a change of the status in an on-boarded VNF package. Only changes in the \"operationalState\" attribute of an on-boarded VNF package and the deletion NF package will be reported. Changes in the \"usageState\" and \"onboardingState\" attributes are not reported. The notification shall be triggered by the NFVO when there is a change in the status of an onboarded VNF package, as follows: * The \"operationalState\" attribute of a VNF package has changed, and the \"onboardingState\" attribute of the package has the value \"ONBOARDED\"\n (i.e. the package has been onboarded previously).\n* The on-boarded VNF package has been deleted, and the \"onboardingState\" attribute of the deleted package had the value \"ONBOARDED\".\n","type":"object","required":["id","notificationType","subscriptionId","timeStamp","vnfPkgId","vnfdId","changeType","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"VnfPackageChangeNotification\" for this notification type.\n","type":"string","enum":["VnfPackageChangeNotification"]},"subscriptionId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfPkgId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"changeType":{"description":"- OP_STATE_CHANGE: The \"operationalState\" attribute has been changed. - PKG_DELETE: The VNF package has been deleted.\n","type":"string","enum":["OP_STATE_CHANGE","PKG_DELETE"]},"operationalState":{"description":"- ENABLED: The VNF package is enabled, i.e. it can be used for the creation of new \"Individual VNF instance\" resources.\n- DISABLED: The VNF package is disabled, i.e. it shall not be used for the creation of further \"Individual VNF instance\" resources\n (unless and until the VNF package is re-enabled).\n","type":"string","enum":["ENABLED","DISABLED"]},"_links":{"description":"This type represents the links to resources that a VNF package management notification can contain.\n","type":"object","required":["vnfPackage","subscription"],"properties":{"vnfPackage":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"vnfPackageByVnfdId":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"subscription":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true}},"responses":{"VnfPackageOnboardingNotification.Post.204":{"description":"204 NO CONTENT\n\nShall be returned when the notification has been delivered successfully.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","style":"simple","explode":false,"schema":{"type":"string"}}}},"VnfPackageOnboardingNotification.Get.204":{"description":"204 NO CONTENT\n\nShall be returned to indicate that the notification endpoint has been tested successfully.\nThe response body shall be empty.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","style":"simple","explode":false,"schema":{"type":"string"}}}},"VnfPackageChangeNotification.Post.204":{"description":"204 NO CONTENT\n\nShall be returned when the notification has been delivered successfully.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","style":"simple","explode":false,"schema":{"type":"string"}}}},"VnfPackageChangeNotification.Get.204":{"description":"204 NO CONTENT\n\nShall be returned to indicate that the notification endpoint has been tested successfully.\nThe response body shall be empty.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","style":"simple","explode":false,"schema":{"type":"string"}}}}}}} diff --git a/v5.3.1/SOL003-VNFPackageManagementNotification-API.yaml b/v5.3.1/SOL003-VNFPackageManagementNotification-API.yaml new file mode 100644 index 00000000..b59ec5e9 --- /dev/null +++ b/v5.3.1/SOL003-VNFPackageManagementNotification-API.yaml @@ -0,0 +1,3186 @@ +openapi: 3.0.2 +info: + title: SOL003 - VNF Package Management Notification interface + description: | + SOL003 - VNF Package Management Notification interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '2.12.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 003 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf +servers: + - url: 'http://127.0.0.1/callback/v2' + - url: 'https://127.0.0.1/callback/v2' +paths: + /URI_is_provided_by_the_client_when_creating_the_subscription-VnfPackageOnboardingNotification: + parameters: + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + post: + description: > + The POST method delivers a notification from the API producer to an API + consumer. + + The API consumer shall have previously created an "Individual + subscription" resource with a matching filter. + + See clause 10.4.9.3.1. + parameters: + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/VnfPackageOnboardingNotification' + responses: + '204': + $ref: '#/components/responses/VnfPackageOnboardingNotification.Post.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + get: + description: > + The GET method allows the API producer to test the notification endpoint + that is provided by the API consumer, + + e.g. during subscription. See clause 10.4.9.3.2. + responses: + '204': + $ref: '#/components/responses/VnfPackageOnboardingNotification.Get.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /URI_is_provided_by_the_client_when_creating_the_subscription-VnfPackageChangeNotification: + parameters: + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + post: + description: > + The POST method delivers a notification from the API producer to an API + consumer. + + The API consumer shall have previously created an "Individual + subscription" resource with a matching filter. + + See clause 10.4.9.3.1. + parameters: + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/VnfPackageChangeNotification' + responses: + '204': + $ref: '#/components/responses/VnfPackageChangeNotification.Post.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + get: + description: > + The GET method allows the API producer to test the notification endpoint + that is provided by the API consumer, + + e.g. during subscription. See clause 10.4.9.3.2. + responses: + '204': + $ref: '#/components/responses/VnfPackageChangeNotification.Get.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + requestBodies: + VnfPackageOnboardingNotification: + description: A notification about on-boarding of a VNF package. + content: + application/json: + schema: + description: > + This type represents a VNF package management notification, which + informs the receiver that the onboarding process of a VNF package + is complete and the package is ready for use. The notification + shall be triggered by the NFVO when the "onboardingState" + attribute of a new VNF package has changed to "ONBOARDED". + type: object + required: + - id + - notificationType + - subscriptionId + - timeStamp + - vnfPkgId + - vnfdId + - vnfmInfo + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall be + set to "VnfPackageOnboardingNotification" for this + notification type. + type: string + enum: + - VnfPackageOnboardingNotification + subscriptionId: + description: | + An identifier with the intention of being globally unique. + type: string + timeStamp: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + vnfPkgId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfmInfo: + description: > + Specifies VNFMs compatible with the VNF. This information is + copied from the VNFD. See table 10.5.2.2-1. + type: array + items: + description: | + A string defined in IETF RFC 8259. + type: string + _links: + description: > + This type represents the links to resources that a VNF package + management notification can contain. + type: object + required: + - vnfPackage + - subscription + properties: + vnfPackage: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfPackageByVnfdId: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + subscription: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + VnfPackageChangeNotification: + description: | + A notification about changes of status in a VNF package.= + content: + application/json: + schema: + description: > + This type represents a VNF package management notification, which + informs the receiver of a change of the status in an on-boarded + VNF package. Only changes in the "operationalState" attribute of + an on-boarded VNF package and the deletion NF package will be + reported. Changes in the "usageState" and "onboardingState" + attributes are not reported. The notification shall be triggered + by the NFVO when there is a change in the status of an onboarded + VNF package, as follows: * The "operationalState" attribute of a + VNF package has changed, and the + "onboardingState" attribute of the package has the value "ONBOARDED" + (i.e. the package has been onboarded previously). + * The on-boarded VNF package has been deleted, and the + "onboardingState" + attribute of the deleted package had the value "ONBOARDED". + type: object + required: + - id + - notificationType + - subscriptionId + - timeStamp + - vnfPkgId + - vnfdId + - changeType + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall be + set to "VnfPackageChangeNotification" for this notification + type. + type: string + enum: + - VnfPackageChangeNotification + subscriptionId: + description: | + An identifier with the intention of being globally unique. + type: string + timeStamp: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + vnfPkgId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + changeType: + description: > + - OP_STATE_CHANGE: The "operationalState" attribute has been + changed. - PKG_DELETE: The VNF package has been deleted. + type: string + enum: + - OP_STATE_CHANGE + - PKG_DELETE + operationalState: + description: > + - ENABLED: The VNF package is enabled, i.e. it can be used for + the creation of new "Individual VNF instance" resources. + - DISABLED: The VNF package is disabled, i.e. it shall not be + used for + the creation of further "Individual VNF instance" resources + (unless and until the VNF package is re-enabled). + type: string + enum: + - ENABLED + - DISABLED + _links: + description: > + This type represents the links to resources that a VNF package + management notification can contain. + type: object + required: + - vnfPackage + - subscription + properties: + vnfPackage: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + vnfPackageByVnfdId: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + subscription: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + responses: + VnfPackageOnboardingNotification.Post.204: + description: | + 204 NO CONTENT + + Shall be returned when the notification has been delivered successfully. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: | + Version of the API used in the response. + style: simple + explode: false + schema: + type: string + VnfPackageOnboardingNotification.Get.204: + description: > + 204 NO CONTENT + + + Shall be returned to indicate that the notification endpoint has been + tested successfully. + + The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: | + Version of the API used in the response. + style: simple + explode: false + schema: + type: string + VnfPackageChangeNotification.Post.204: + description: | + 204 NO CONTENT + + Shall be returned when the notification has been delivered successfully. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: | + Version of the API used in the response. + style: simple + explode: false + schema: + type: string + VnfPackageChangeNotification.Get.204: + description: > + 204 NO CONTENT + + + Shall be returned to indicate that the notification endpoint has been + tested successfully. + + The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: | + Version of the API used in the response. + style: simple + explode: false + schema: + type: string + diff --git a/v5.3.1/SOL003-VNFPerformanceManagement-API.json b/v5.3.1/SOL003-VNFPerformanceManagement-API.json new file mode 100644 index 00000000..3a959bae --- /dev/null +++ b/v5.3.1/SOL003-VNFPerformanceManagement-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL003 - VNF Performance Management interface","description":"SOL003 - VNF Performance Management interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"2.13.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 003 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/vnfpm/v2"},{"url":"https://127.0.0.1/vnfpm/v2"}],"paths":{"/api-versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/pm_jobs":{"parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"post":{"description":"The POST method creates a PM job. See clause 6.4.2.3.1.\n","parameters":[{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/CreatePmJobRequest"},"responses":{"201":{"$ref":"#/components/responses/PmJobs.Post.201"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/PmJobs.Post.422"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"get":{"description":"The API consumer can use this method to retrieve information about PM jobs. See clause 6.4.2.3.2.\n","parameters":[{"$ref":"#/components/parameters/filter_pm_jobs"},{"name":"all_fields","description":"Include all complex attributes in the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM shall support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"fields","description":"Complex attributes to be included into the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"exclude_fields","description":"Complex attributes to be excluded from the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"$ref":"#/components/parameters/exclude_default_pm_jobs"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/PmJobs.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/pm_jobs/{pmJobId}":{"parameters":[{"$ref":"#/components/parameters/PmJobId"},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"get":{"description":"The API consumer can use this method for reading an individual PM job. See clause 6.4.3.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualPmJob.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method allows to modify an \"Individual PM job\" resource. See clause 6.4.3.3.4.\n","parameters":[{"name":"If-Unmodified-Since","description":"Used to make the request method conditional on the selected resource representation's last modification date being earlier than or equal to the date provided in the field-value. If the condition is not met, the request fails with a \"412 Precondition Failed\" response.\n","required":false,"in":"header","schema":{"type":"string","format":"date-time"}},{"name":"If-Match","description":"Used to make the request method conditional on the recipient origin server either having at least one current representation of the target resource, when the field-value is \"*\", or having a current representation of the target resource that has an entity-tag matching a member of the list of entity-tags provided in the field-value. If the condition is not met, the request fails with a \"412 Precondition Failed\" response.\n","required":false,"in":"header","schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/PmJobModificationRequest"},"responses":{"200":{"$ref":"#/components/responses/IndividualPmJob.Patch.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/IndividualPmJob.Patch.412"},"422":{"$ref":"#/components/responses/IndividualPmJob.Patch.422"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method terminates an individual PM job. See clause 6.4.3.3.5.\n","responses":{"204":{"$ref":"#/components/responses/IndividualPmJob.Delete.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/pm_jobs/{pmJobId}/reports/{reportId}":{"parameters":[{"$ref":"#/components/parameters/PmJobId"},{"$ref":"#/components/parameters/ReportId"}],"get":{"description":"The API consumer can use this method for reading an individual performance report. See clause 6.4.4.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualPerformanceReport.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/thresholds":{"parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"post":{"description":"The POST method can be used by the API consumer to create a threshold. See clause 6.4.5.3.1.\n","parameters":[{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/CreateThresholdRequest"},"responses":{"201":{"$ref":"#/components/responses/Thresholds.Post.201"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/Thresholds.Post.422"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"get":{"description":"The API consumer can use this method to query information about thresholds. See clause 6.4.5.3.2.\n","parameters":[{"$ref":"#/components/parameters/filter_thresholds"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/Thresholds.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/thresholds/{thresholdId}":{"parameters":[{"$ref":"#/components/parameters/ThresholdId"},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"get":{"description":"The API consumer can use this method for reading an individual threshold. See clause 6.4.6.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualThreshold.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method allows to modify an \"Individual threshold\" resource. See clause 6.4.6.3.4.\n","parameters":[{"name":"If-Unmodified-Since","description":"Used to make the request method conditional on the selected resource representation's last modification date being earlier than or equal to the date provided in the field-value. If the condition is not met, the request fails with a \"412 Precondition Failed\" response.\n","required":false,"in":"header","schema":{"type":"string","format":"date-time"}},{"name":"If-Match","description":"Used to make the request method conditional on the recipient origin server either having at least one current representation of the target resource, when the field-value is \"*\", or having a current representation of the target resource that has an entity-tag matching a member of the list of entity-tags provided in the field-value. If the condition is not met, the request fails with a \"412 Precondition Failed\" response.\n","required":false,"in":"header","schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/ThresholdModificationRequest"},"responses":{"200":{"$ref":"#/components/responses/IndividualThreshold.Patch.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/IndividualThreshold.Patch.412"},"422":{"$ref":"#/components/responses/IndividualThreshold.Patch.422"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method allows to delete a threshold. See clause 6.4.6.3.5.\n","responses":{"204":{"$ref":"#/components/responses/IndividualThreshold.Delete.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"parameters":{"filter_pm_jobs":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part of the URI query string. The NFVO may supply this parameter. All attribute names that appear in the PmJob and in data types referenced from it shall be supported by the VNFM in the filter expression.\n","in":"query","required":false,"schema":{"type":"string"}},"exclude_default_pm_jobs":{"name":"exclude_default","in":"query","description":"Indicates to exclude the following complex attributes from the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM shall support this parameter. The following attributes shall be excluded from the PmJob structure in the response body if this parameter is provided, or none of the parameters \"all_fields,\" \"fields\", \"exclude_fields\", \"exclude_default\" are provided: - reports","required":false,"schema":{"type":"string"}},"filter_thresholds":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part of the URI query string. The NFVO may supply this parameter. All attribute names that appear in the Thresholds data type and in data types referenced from it shall be supported by the VNFM in the filter expression\n","in":"query","required":false,"schema":{"type":"string"}},"PmJobId":{"name":"pmJobId","in":"path","description":"Identifier of the PM job.\nThis identifier can be retrieved from the resource referenced by the\n\"Location\" HTTP header in the response to a POST request creating a\nnew \"Individual PM job\" resource. It can also be retrieved from the \"id\"\nattribute in the message content of that response.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"ReportId":{"name":"reportId","in":"path","description":"Identifier of the performance report.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"ThresholdId":{"name":"thresholdId","in":"path","description":"Identifier of the threshold.\nThis identifier can be retrieved from the resource referenced by the\n\"Location\" HTTP header in the response to a POST request creating a\nnew \"Individual threshold\" resource. It can also be retrieved from the \"id\"\nattribute in the message content of that response.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}}},"requestBodies":{"CreatePmJobRequest":{"description":"The VNF creation parameters","content":{"application/json":{"schema":{"description":"This type represents a request to create a PM job.\n","type":"object","required":["objectType","objectInstanceIds","criteria","callbackUri"],"properties":{"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceIds":{"description":"Identifiers of the measured object instances for which performance information is requested to be collected.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance for which performance information is requested to be collected. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027for the related measured object type. If this attribute is present, the cardinality of the \"objectInstanceIds\" attribute shall be 1. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV IFA 027 for the related measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents collection criteria for PM jobs.\nNOTE 1:\tAt the end of each reportingPeriod, the API producer will inform the API consumer about availability of the \n performance data collected for each completed collection period during this reportingPeriod. \n The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance \n data for the collection periods within one reporting period are reported together.\nNOTE 2:\tIn particular when choosing short collection and reporting periods, the number of PM jobs that can be supported \n depends on the capability of the producing entity.\n","type":"object","required":["collectionPeriod","reportingPeriod"],"properties":{"performanceMetric":{"description":"This defines the types of performance metrics for the specified object instances. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"performanceMetricGroup":{"description":"Group of performance metrics. A metric group is a pre-defined list of metrics, known to the API producer that it can decompose to individual metrics. Valid values are specified as \"Measurement Group\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"collectionPeriod":{"description":"SSpecifies the periodicity at which the API producer will collect performance information. The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingPeriod":{"description":"Specifies the periodicity at which the API producer will report to the API consumer about performance information. The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingBoundary":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE 1 : The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between\n subscriptions. The value of clientPassword should be generated by a random process.\n* NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT which uses mutual authentication based on X.509 certificates, this mode which uses client password to authenticate may be used in the access token request\n toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations\n (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details.\n* NOTE 3: The following values that were included up to version 3.4.1 of the present document have been removed: \"BASIC\" (to signal the use of the basic HTTP authentication) has been removed because it is insecure.\n \"TLS_CERT\" to signal an alternative non-token based authorization method using TLS certificates has been\n removed because the method is no longer supported.\n* NOTE 4: The client certificate is established by means outside the scope of the present document.\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values (see note 3): * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use\n an OAuth 2.0 token, obtained using the client\n credentials grant type after authenticating\n using client identifier and client password\n towards the token endpoint.\n* OAUTH2_CLIENT_CERT: In every HTTP request to the notification endpoint, use an\n OAuth 2.0 token, obtained using the client\n credentials grant type after mutually\n authenticating using client identifier and X.509\n certificates towards the token endpoint.\n","type":"array","items":{"type":"string","enum":["OAUTH2_CLIENT_CREDENTIALS","OAUTH2_CLIENT_CERT"]}},"paramsOauth2ClientCert":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CERT.\nShall be present if authType is \"OAUTH2_CLIENT_CERT\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\n","type":"object","required":["clientId","certificateRef","tokenEndpoint"],"properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint.\n","type":"string"},"certificateRef":{"description":"Fingerprint of the client certificate. The hash function shall use SHA256 or higher. See note 4.\n","type":"string","required":["type","value"],"properties":{"type":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"value":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS.\nShall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\nSee note 2.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"clientPassword":{"description":"Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true},"PmJobModificationRequest":{"description":"Parameters for the PM job modification","content":{"application/merge-patch+json":{"schema":{"description":"This type represents modifications to a PM job.\nNOTE:\tAt least one of the attributes defined in this type shall be present in request bodies.\n","type":"object","oneOf":[{"required":["callbackUri"]},{"required":["authentication"]}],"properties":{"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE 1 : The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between\n subscriptions. The value of clientPassword should be generated by a random process.\n* NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT which uses mutual authentication based on X.509 certificates, this mode which uses client password to authenticate may be used in the access token request\n toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations\n (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details.\n* NOTE 3: The following values that were included up to version 3.4.1 of the present document have been removed: \"BASIC\" (to signal the use of the basic HTTP authentication) has been removed because it is insecure.\n \"TLS_CERT\" to signal an alternative non-token based authorization method using TLS certificates has been\n removed because the method is no longer supported.\n* NOTE 4: The client certificate is established by means outside the scope of the present document.\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values (see note 3): * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use\n an OAuth 2.0 token, obtained using the client\n credentials grant type after authenticating\n using client identifier and client password\n towards the token endpoint.\n* OAUTH2_CLIENT_CERT: In every HTTP request to the notification endpoint, use an\n OAuth 2.0 token, obtained using the client\n credentials grant type after mutually\n authenticating using client identifier and X.509\n certificates towards the token endpoint.\n","type":"array","items":{"type":"string","enum":["OAUTH2_CLIENT_CREDENTIALS","OAUTH2_CLIENT_CERT"]}},"paramsOauth2ClientCert":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CERT.\nShall be present if authType is \"OAUTH2_CLIENT_CERT\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\n","type":"object","required":["clientId","certificateRef","tokenEndpoint"],"properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint.\n","type":"string"},"certificateRef":{"description":"Fingerprint of the client certificate. The hash function shall use SHA256 or higher. See note 4.\n","type":"string","required":["type","value"],"properties":{"type":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"value":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS.\nShall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\nSee note 2.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"clientPassword":{"description":"Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true},"CreateThresholdRequest":{"description":"Request parameters to create a threshold resource.","content":{"application/json":{"schema":{"description":"This type represents a request to create a threshold.\n","type":"object","required":["objectType","objectInstanceId","criteria","callbackUri"],"properties":{"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance associated with this threshold. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents criteria that define a threshold.\nNOTE 1:\tIn the present document, simple thresholds are defined. The definition of additional threshold types is left for \n future specification.\nNOTE 2:\tThe hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create \n a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or \n reject the request). \n","type":"object","required":["performanceMetric","thresholdType"],"properties":{"performanceMetric":{"description":"Defines the performance metric associated with the threshold. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"thresholdType":{"description":"Type of threshold. This attribute determines which other attributes are present in the data structure.\nPermitted values: -\tSIMPLE: Single-valued static threshold. See note 1.\n","type":"string","enum":["SIMPLE"]},"simpleThresholdDetails":{"description":"Details of a simple threshold. Shall be present if thresholdType=\"SIMPLE\".\n","type":"object","required":["thresholdValue","hysteresis"],"properties":{"thresholdValue":{"description":"The threshold value. Shall be represented as a floating point number.\n","type":"number","format":"float"},"hysteresis":{"description":"The hysteresis of the threshold. Shall be represented as a non-negative floating point number.\nA notification with crossing direction \"UP\" will be generated if the measured value reaches or exceeds \"thresholdValue\" + \"hysteresis\". A notification with crossing direction \"DOWN\" will be generated if the measured value reaches or undercuts \"thresholdValue\" - \"hysteresis\". See note 2.\n","type":"number","minimum":0,"maximum":1024,"format":"float"}}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE 1 : The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between\n subscriptions. The value of clientPassword should be generated by a random process.\n* NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT which uses mutual authentication based on X.509 certificates, this mode which uses client password to authenticate may be used in the access token request\n toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations\n (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details.\n* NOTE 3: The following values that were included up to version 3.4.1 of the present document have been removed: \"BASIC\" (to signal the use of the basic HTTP authentication) has been removed because it is insecure.\n \"TLS_CERT\" to signal an alternative non-token based authorization method using TLS certificates has been\n removed because the method is no longer supported.\n* NOTE 4: The client certificate is established by means outside the scope of the present document.\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values (see note 3): * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use\n an OAuth 2.0 token, obtained using the client\n credentials grant type after authenticating\n using client identifier and client password\n towards the token endpoint.\n* OAUTH2_CLIENT_CERT: In every HTTP request to the notification endpoint, use an\n OAuth 2.0 token, obtained using the client\n credentials grant type after mutually\n authenticating using client identifier and X.509\n certificates towards the token endpoint.\n","type":"array","items":{"type":"string","enum":["OAUTH2_CLIENT_CREDENTIALS","OAUTH2_CLIENT_CERT"]}},"paramsOauth2ClientCert":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CERT.\nShall be present if authType is \"OAUTH2_CLIENT_CERT\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\n","type":"object","required":["clientId","certificateRef","tokenEndpoint"],"properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint.\n","type":"string"},"certificateRef":{"description":"Fingerprint of the client certificate. The hash function shall use SHA256 or higher. See note 4.\n","type":"string","required":["type","value"],"properties":{"type":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"value":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS.\nShall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\nSee note 2.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"clientPassword":{"description":"Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true},"ThresholdModificationRequest":{"description":"Parameters for the threshold modification.","content":{"application/merge-patch+json":{"schema":{"description":"This type represents modifications to a threshold.\nNOTE:\tAt least one of the attributes defined in this type shall be present in request bodies.\n","type":"object","oneOf":[{"required":["callbackUri"]},{"required":["authentication"]}],"properties":{"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE 1 : The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between\n subscriptions. The value of clientPassword should be generated by a random process.\n* NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT which uses mutual authentication based on X.509 certificates, this mode which uses client password to authenticate may be used in the access token request\n toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations\n (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details.\n* NOTE 3: The following values that were included up to version 3.4.1 of the present document have been removed: \"BASIC\" (to signal the use of the basic HTTP authentication) has been removed because it is insecure.\n \"TLS_CERT\" to signal an alternative non-token based authorization method using TLS certificates has been\n removed because the method is no longer supported.\n* NOTE 4: The client certificate is established by means outside the scope of the present document.\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values (see note 3): * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use\n an OAuth 2.0 token, obtained using the client\n credentials grant type after authenticating\n using client identifier and client password\n towards the token endpoint.\n* OAUTH2_CLIENT_CERT: In every HTTP request to the notification endpoint, use an\n OAuth 2.0 token, obtained using the client\n credentials grant type after mutually\n authenticating using client identifier and X.509\n certificates towards the token endpoint.\n","type":"array","items":{"type":"string","enum":["OAUTH2_CLIENT_CREDENTIALS","OAUTH2_CLIENT_CERT"]}},"paramsOauth2ClientCert":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CERT.\nShall be present if authType is \"OAUTH2_CLIENT_CERT\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\n","type":"object","required":["clientId","certificateRef","tokenEndpoint"],"properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint.\n","type":"string"},"certificateRef":{"description":"Fingerprint of the client certificate. The hash function shall use SHA256 or higher. See note 4.\n","type":"string","required":["type","value"],"properties":{"type":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"value":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS.\nShall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\nSee note 2.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"clientPassword":{"description":"Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true}},"responses":{"PmJobs.Post.201":{"description":"201 CREATED\n\nShall be returned when the PM job has been created successfully.\nThe response body shall contain a representation of the created \"Individual PM job\" resource,\nas defined in clause 6.5.2.7.\nThe HTTP response shall include a \"Location\" HTTP header that points to the created\n\"Individual PM job\" resource.\n","headers":{"Location":{"description":"The resource URI of the created PM Job","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a PM job.\n","type":"object","required":["id","objectType","objectInstanceIds","criteria","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceIds":{"description":"Identifiers of the VNF instances for which performance information is collected.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance for which performance information is requested to be collected. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type. If this attribute is present, the cardinality of the \"objectInstanceIds\" attribute shall be 1. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV IFA 027 for the related measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents collection criteria for PM jobs.\nNOTE 1:\tAt the end of each reportingPeriod, the API producer will inform the API consumer about availability of the \n performance data collected for each completed collection period during this reportingPeriod. \n The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance \n data for the collection periods within one reporting period are reported together.\nNOTE 2:\tIn particular when choosing short collection and reporting periods, the number of PM jobs that can be supported \n depends on the capability of the producing entity.\n","type":"object","required":["collectionPeriod","reportingPeriod"],"properties":{"performanceMetric":{"description":"This defines the types of performance metrics for the specified object instances. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"performanceMetricGroup":{"description":"Group of performance metrics. A metric group is a pre-defined list of metrics, known to the API producer that it can decompose to individual metrics. Valid values are specified as \"Measurement Group\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"collectionPeriod":{"description":"SSpecifies the periodicity at which the API producer will collect performance information. The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingPeriod":{"description":"Specifies the periodicity at which the API producer will report to the API consumer about performance information. The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingBoundary":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"reports":{"description":"Information about available reports collected by this PM job.\n","type":"object","required":["href","readyTime"],"properties":{"href":{"description":"The URI where the report can be obtained.\n","type":"string","format":"url"},"readyTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"expiryTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"fileSize":{"description":"The size of the report file in bytes, if known.\n","type":"integer","minimum":0}}},"pmJobConnection":{"description":"An access information and interface information of PM job to monitor the PM of VNF instance by the VNFM. This can include for instance certain interface endpoint URI together with necessary credentials to access it.\n","type":"array","items":{"description":"The MonitoringConnection shall follow the indications provided.\n* NOTE: The VNFM can be made aware of monitoring connection information, including their identifiers to be used by configuration means outside the scope of the \n present document (e.g. using relevant NFV-MANO management APIs as defined in \n ETSI GS NFV-SOL 009 [i.18]).\n","type":"object","required":["id","monitoringType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"monitoringType":{"description":"Type of monitoring way.\n","type":"string","enum":["VIM_CISM","EXTERNAL","PAAS"]},"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"objects":{"description":"Links to resources representing the measure object instances for which performance information is collected. Shall be present if the measured object instance information is accessible as a resource.\n","type":"array","items":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"PmJobs.Post.422":{"description":"422 Unprocessable Content\n\nShall be returned upon the following error: The\ncontent type of the message content is supported and\nthe message content of a request contains syntactically\ncorrect data but the data cannot be processed.\nThe general cause for this error and its handling is\nspecified in clause 6.4 of ETSI GS NFV-SOL 013 [8],\nincluding rules for the presence of the response\nbody.\nSpecifically in case of this resource, the response\ncode 422 shall also be returned if the VNFM has\ntested the Notification endpoint as described in\nclause 6.4.9.3.2 and the test has failed.\nIn this case, the \"detail\" attribute in the\n\"ProblemDetails\" structure sh\n","headers":{"Location":{"description":"The resource URI of the created PM Job","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"PmJobs.Get.200":{"description":"200 OK\n\nShall be returned when information about zero or more PM jobs has been queried successfully.\nThe response body shall contain in an array the representations of zero or more PM jobs,\nas defined in clause 6.5.2.7.\nIf the \"filter\" URI parameter or one of the \"all_fields\", \"fields\" (if supported), \"exclude_fields\"\n(if supported) or \"exclude_default\" URI parameters was supplied in the request, the data in the\nresponse body shall have been transformed according to the rules specified in clauses 5.2.2 and 5.3.2\nof ETSI GS NFV-SOL 013, respectively.\nIf the VNFM supports alternative 2 (paging) according to clause 5.4..2.1 of ETSI GS NFV-SOL 013\nfor this resource, inclusion of the Link HTTP header in this response shall follow the provisions\nin clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a PM job.\n","type":"object","required":["id","objectType","objectInstanceIds","criteria","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceIds":{"description":"Identifiers of the VNF instances for which performance information is collected.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance for which performance information is requested to be collected. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type. If this attribute is present, the cardinality of the \"objectInstanceIds\" attribute shall be 1. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV IFA 027 for the related measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents collection criteria for PM jobs.\nNOTE 1:\tAt the end of each reportingPeriod, the API producer will inform the API consumer about availability of the \n performance data collected for each completed collection period during this reportingPeriod. \n The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance \n data for the collection periods within one reporting period are reported together.\nNOTE 2:\tIn particular when choosing short collection and reporting periods, the number of PM jobs that can be supported \n depends on the capability of the producing entity.\n","type":"object","required":["collectionPeriod","reportingPeriod"],"properties":{"performanceMetric":{"description":"This defines the types of performance metrics for the specified object instances. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"performanceMetricGroup":{"description":"Group of performance metrics. A metric group is a pre-defined list of metrics, known to the API producer that it can decompose to individual metrics. Valid values are specified as \"Measurement Group\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"collectionPeriod":{"description":"SSpecifies the periodicity at which the API producer will collect performance information. The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingPeriod":{"description":"Specifies the periodicity at which the API producer will report to the API consumer about performance information. The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingBoundary":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"reports":{"description":"Information about available reports collected by this PM job.\n","type":"object","required":["href","readyTime"],"properties":{"href":{"description":"The URI where the report can be obtained.\n","type":"string","format":"url"},"readyTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"expiryTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"fileSize":{"description":"The size of the report file in bytes, if known.\n","type":"integer","minimum":0}}},"pmJobConnection":{"description":"An access information and interface information of PM job to monitor the PM of VNF instance by the VNFM. This can include for instance certain interface endpoint URI together with necessary credentials to access it.\n","type":"array","items":{"description":"The MonitoringConnection shall follow the indications provided.\n* NOTE: The VNFM can be made aware of monitoring connection information, including their identifiers to be used by configuration means outside the scope of the \n present document (e.g. using relevant NFV-MANO management APIs as defined in \n ETSI GS NFV-SOL 009 [i.18]).\n","type":"object","required":["id","monitoringType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"monitoringType":{"description":"Type of monitoring way.\n","type":"string","enum":["VIM_CISM","EXTERNAL","PAAS"]},"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"objects":{"description":"Links to resources representing the measure object instances for which performance information is collected. Shall be present if the measured object instance information is accessible as a resource.\n","type":"array","items":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}}},"IndividualPmJob.Get.200":{"description":"200 OK\n\nShall be returned when information about an individual PM job has been read successfully.\nThe response body shall contain a representation of the \"Individual PM job\" resource,\nas defined in clause 6.5.2.7.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a PM job.\n","type":"object","required":["id","objectType","objectInstanceIds","criteria","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceIds":{"description":"Identifiers of the VNF instances for which performance information is collected.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance for which performance information is requested to be collected. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type. If this attribute is present, the cardinality of the \"objectInstanceIds\" attribute shall be 1. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV IFA 027 for the related measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents collection criteria for PM jobs.\nNOTE 1:\tAt the end of each reportingPeriod, the API producer will inform the API consumer about availability of the \n performance data collected for each completed collection period during this reportingPeriod. \n The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance \n data for the collection periods within one reporting period are reported together.\nNOTE 2:\tIn particular when choosing short collection and reporting periods, the number of PM jobs that can be supported \n depends on the capability of the producing entity.\n","type":"object","required":["collectionPeriod","reportingPeriod"],"properties":{"performanceMetric":{"description":"This defines the types of performance metrics for the specified object instances. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"performanceMetricGroup":{"description":"Group of performance metrics. A metric group is a pre-defined list of metrics, known to the API producer that it can decompose to individual metrics. Valid values are specified as \"Measurement Group\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"collectionPeriod":{"description":"SSpecifies the periodicity at which the API producer will collect performance information. The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingPeriod":{"description":"Specifies the periodicity at which the API producer will report to the API consumer about performance information. The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingBoundary":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"reports":{"description":"Information about available reports collected by this PM job.\n","type":"object","required":["href","readyTime"],"properties":{"href":{"description":"The URI where the report can be obtained.\n","type":"string","format":"url"},"readyTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"expiryTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"fileSize":{"description":"The size of the report file in bytes, if known.\n","type":"integer","minimum":0}}},"pmJobConnection":{"description":"An access information and interface information of PM job to monitor the PM of VNF instance by the VNFM. This can include for instance certain interface endpoint URI together with necessary credentials to access it.\n","type":"array","items":{"description":"The MonitoringConnection shall follow the indications provided.\n* NOTE: The VNFM can be made aware of monitoring connection information, including their identifiers to be used by configuration means outside the scope of the \n present document (e.g. using relevant NFV-MANO management APIs as defined in \n ETSI GS NFV-SOL 009 [i.18]).\n","type":"object","required":["id","monitoringType"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"monitoringType":{"description":"Type of monitoring way.\n","type":"string","enum":["VIM_CISM","EXTERNAL","PAAS"]},"vimId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"paasServiceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"interfaceInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"accessInfo":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"extra":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}}},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"objects":{"description":"Links to resources representing the measure object instances for which performance information is collected. Shall be present if the measured object instance information is accessible as a resource.\n","type":"array","items":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"IndividualPmJob.Patch.200":{"description":"200 OK\n\nShall be returned when the request has been processed successfully.\nThe response body shall contain a data structure of type \"PmJobModifications\".\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"ETag":{"description":"Used to provide the current entity-tag for the selected resource representation. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string"}},"Last-Modified":{"description":"Used to provide a timestamp indicating the date and time at which the server believes the selected resource representation was last modified. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string","format":"date-time"}}},"content":{"application/json":{"schema":{"description":"This type represents modifications to a PM job.\nNOTE:\tAt least one of the attributes defined in this type shall be present in request bodies.\n","type":"object","oneOf":[{"required":["callbackUri"]},{"required":["authentication"]}],"properties":{"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE 1 : The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between\n subscriptions. The value of clientPassword should be generated by a random process.\n* NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT which uses mutual authentication based on X.509 certificates, this mode which uses client password to authenticate may be used in the access token request\n toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations\n (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details.\n* NOTE 3: The following values that were included up to version 3.4.1 of the present document have been removed: \"BASIC\" (to signal the use of the basic HTTP authentication) has been removed because it is insecure.\n \"TLS_CERT\" to signal an alternative non-token based authorization method using TLS certificates has been\n removed because the method is no longer supported.\n* NOTE 4: The client certificate is established by means outside the scope of the present document.\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values (see note 3): * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use\n an OAuth 2.0 token, obtained using the client\n credentials grant type after authenticating\n using client identifier and client password\n towards the token endpoint.\n* OAUTH2_CLIENT_CERT: In every HTTP request to the notification endpoint, use an\n OAuth 2.0 token, obtained using the client\n credentials grant type after mutually\n authenticating using client identifier and X.509\n certificates towards the token endpoint.\n","type":"array","items":{"type":"string","enum":["OAUTH2_CLIENT_CREDENTIALS","OAUTH2_CLIENT_CERT"]}},"paramsOauth2ClientCert":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CERT.\nShall be present if authType is \"OAUTH2_CLIENT_CERT\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\n","type":"object","required":["clientId","certificateRef","tokenEndpoint"],"properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint.\n","type":"string"},"certificateRef":{"description":"Fingerprint of the client certificate. The hash function shall use SHA256 or higher. See note 4.\n","type":"string","required":["type","value"],"properties":{"type":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"value":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS.\nShall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\nSee note 2.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"clientPassword":{"description":"Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualPmJob.Patch.412":{"description":"412 Precondition Failed\n\nShall be returned upon the following error: A\nprecondition given in an HTTP request header is not\nfulfilled.\nTypically, this is due to an ETag mismatch, indicating\nthat the resource was modified by another entity.\nThe response body should contain a ProblemDetails\nstructure, in which the \"detail\" attribute should convey\nmore information about the error.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualPmJob.Patch.422":{"description":"422 Unprocessable Content\n\nShall be returned upon the following error: The\ncontent type of the message content is supported and the\nmessage content of a request contains syntactically\ncorrect data but the data cannot be processed.\nThe general cause for this error and its handling is\nspecified in clause 6.4 of ETSI GS NFV-SOL 013 [8],\nincluding rules for the presence of the response body.\nSpecifically in case of this resource, the response\ncode 422 shall also be returned if the VNFM has\ntested the Notification endpoint as described in\nclause 6.4.9.3.2 and the test has failed.\nIn this case, the \"detail\" attribute in the\n\"ProblemDetails\" structure shall convey more\ninformation about the error.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualPmJob.Delete.200":{"description":"204 NO CONTENT\n\nShall be returned when the PM job has been deleted successfully.\nThe response body shall be empty.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualPerformanceReport.Get.200":{"description":"200 OK\n\nShall be returned when information of an individual performance report has been read successfully.\nThe response body shall contain a representation of the \"Individual performance report\" resource,\nas defined in clause 6.5.2.10.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type defines the format of a performance report provided by the VNFM to the NFVO as a result of collecting performance information as part of a PM job.\nNOTE:\tThe sub-object allows to structure the measured object but is not to be confused with sub-counters which allow \n to structure the measurement value.\n\nEXAMPLE:\n Measured object: VnfInstanceXYZ\n Sub-object: VnfcInstance1\n Measurement: vCPU_utilization\n Sub-counters: vCPU utilization of each of the vCPUs of VnfcInstance1 (vCPU utilization.vCPU1, vCPU_utilization.vCPU2, etc.).\n","type":"object","required":["entries"],"properties":{"entries":{"description":"List of performance information entries. Each performance report entry is for a given metric of a given object (i.e. VNF instance), but can include multiple collected values.\n","type":"array","items":{"type":"object","required":["objectType","objectInstanceId","performanceMetric","performanceValue"],"properties":{"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"performanceMetric":{"description":"Name of the metric collected. This attribute shall contain the related \"Measurement Name\" value as defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"performanceValues":{"description":"List of performance values with associated timestamp.\n","type":"array","items":{"type":"object","required":["timeStamp","value"],"properties":{"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"value":{"description":"Value of the metric collected. The type of this attribute shall correspond to the related \"Measurement Unit\" as defined in clause 7.2. of ETSI GS NFV-IFA 027.\n","type":"object"},"context":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}}}}}}}},"Thresholds.Post.201":{"description":"201 CREATED\n\nShall be returned when a threshold has been created successfully.\nThe response body shall contain a representation of the created \"Individual threshold\" resource,\nas defined in clause 6.5.2.9.\nThe HTTP response shall include a \"Location\" HTTP header that contains the resource URI of the\ncreated threshold resource.\n","headers":{"Location":{"description":"TThe resource URI of the created VNF instance","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a threshold.\n","type":"object","required":["id","objectType","objectInstanceId","criteria","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance associated with the threshold. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measurement type. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents criteria that define a threshold.\nNOTE 1:\tIn the present document, simple thresholds are defined. The definition of additional threshold types is left for \n future specification.\nNOTE 2:\tThe hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create \n a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or \n reject the request). \n","type":"object","required":["performanceMetric","thresholdType"],"properties":{"performanceMetric":{"description":"Defines the performance metric associated with the threshold. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"thresholdType":{"description":"Type of threshold. This attribute determines which other attributes are present in the data structure.\nPermitted values: -\tSIMPLE: Single-valued static threshold. See note 1.\n","type":"string","enum":["SIMPLE"]},"simpleThresholdDetails":{"description":"Details of a simple threshold. Shall be present if thresholdType=\"SIMPLE\".\n","type":"object","required":["thresholdValue","hysteresis"],"properties":{"thresholdValue":{"description":"The threshold value. Shall be represented as a floating point number.\n","type":"number","format":"float"},"hysteresis":{"description":"The hysteresis of the threshold. Shall be represented as a non-negative floating point number.\nA notification with crossing direction \"UP\" will be generated if the measured value reaches or exceeds \"thresholdValue\" + \"hysteresis\". A notification with crossing direction \"DOWN\" will be generated if the measured value reaches or undercuts \"thresholdValue\" - \"hysteresis\". See note 2.\n","type":"number","minimum":0,"maximum":1024,"format":"float"}}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"object":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"Thresholds.Post.422":{"description":"422 Unprocessable Content\n\nShall be returned upon the following error: The\ncontent type of the message content is supported and\nthe message content of a request contains\nsyntactically correct data but the data cannot be\nprocessed.\nThe general cause for this error and its handling is\nspecified in clause 6.4 of ETSI\nGS NFV-SOL 013 [8], including rules for the\npresence of the response body.\nSpecifically in case of this resource, the response\ncode 422 shall also be returned if the VNFM has\ntested the Notification endpoint as described in\nclause 6.4.9.3.2 and the test has failed.\nIn this case, the \"detail\" attribute in the\n\"ProblemDetails\" structure shall convey more\ninformation about the error\n","headers":{"Location":{"description":"TThe resource URI of the created VNF instance","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"Thresholds.Get.200":{"description":"200 OK\n\nShall be returned when information about zero or more thresholds has been queried successfully.\nIf the \"filter\" URI parameter was supplied in the request, the data in the response body shall have\nbeen transformed according to the rules specified in clause 5.2.2 of ETSI GS NFV-SOL 013.\nThe response body shall contain in an array the representations of zero or more thresholds,\nas defined in clause 6.5.2.9.\nIf the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013\nfor this resource, inclusion of the Link HTTP header in this response shall follow the provisions\nin clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"Location":{"description":"The resource URI of the created VNF instance","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a threshold.\n","type":"object","required":["id","objectType","objectInstanceId","criteria","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance associated with the threshold. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measurement type. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents criteria that define a threshold.\nNOTE 1:\tIn the present document, simple thresholds are defined. The definition of additional threshold types is left for \n future specification.\nNOTE 2:\tThe hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create \n a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or \n reject the request). \n","type":"object","required":["performanceMetric","thresholdType"],"properties":{"performanceMetric":{"description":"Defines the performance metric associated with the threshold. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"thresholdType":{"description":"Type of threshold. This attribute determines which other attributes are present in the data structure.\nPermitted values: -\tSIMPLE: Single-valued static threshold. See note 1.\n","type":"string","enum":["SIMPLE"]},"simpleThresholdDetails":{"description":"Details of a simple threshold. Shall be present if thresholdType=\"SIMPLE\".\n","type":"object","required":["thresholdValue","hysteresis"],"properties":{"thresholdValue":{"description":"The threshold value. Shall be represented as a floating point number.\n","type":"number","format":"float"},"hysteresis":{"description":"The hysteresis of the threshold. Shall be represented as a non-negative floating point number.\nA notification with crossing direction \"UP\" will be generated if the measured value reaches or exceeds \"thresholdValue\" + \"hysteresis\". A notification with crossing direction \"DOWN\" will be generated if the measured value reaches or undercuts \"thresholdValue\" - \"hysteresis\". See note 2.\n","type":"number","minimum":0,"maximum":1024,"format":"float"}}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"object":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"IndividualThreshold.Get.200":{"description":"200 OK\n\nShall be returned when information about an individual threshold has been read successfully.\nThe response body shall contain a representation of the threshold, as defined in clause 6.5.2.9.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"ETag":{"description":"Used to provide the current entity-tag for the selected resource representation. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string"}},"Last-Modified":{"description":"Used to provide a timestamp indicating the date and time at which the server believes the selected resource representation was last modified. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string","format":"date-time"}}},"content":{"application/json":{"schema":{"description":"This type represents a threshold.\n","type":"object","required":["id","objectType","objectInstanceId","criteria","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance associated with the threshold. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measurement type. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents criteria that define a threshold.\nNOTE 1:\tIn the present document, simple thresholds are defined. The definition of additional threshold types is left for \n future specification.\nNOTE 2:\tThe hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create \n a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or \n reject the request). \n","type":"object","required":["performanceMetric","thresholdType"],"properties":{"performanceMetric":{"description":"Defines the performance metric associated with the threshold. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"thresholdType":{"description":"Type of threshold. This attribute determines which other attributes are present in the data structure.\nPermitted values: -\tSIMPLE: Single-valued static threshold. See note 1.\n","type":"string","enum":["SIMPLE"]},"simpleThresholdDetails":{"description":"Details of a simple threshold. Shall be present if thresholdType=\"SIMPLE\".\n","type":"object","required":["thresholdValue","hysteresis"],"properties":{"thresholdValue":{"description":"The threshold value. Shall be represented as a floating point number.\n","type":"number","format":"float"},"hysteresis":{"description":"The hysteresis of the threshold. Shall be represented as a non-negative floating point number.\nA notification with crossing direction \"UP\" will be generated if the measured value reaches or exceeds \"thresholdValue\" + \"hysteresis\". A notification with crossing direction \"DOWN\" will be generated if the measured value reaches or undercuts \"thresholdValue\" - \"hysteresis\". See note 2.\n","type":"number","minimum":0,"maximum":1024,"format":"float"}}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"_links":{"description":"Links for this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"object":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualThreshold.Patch.200":{"description":"200 OK\n\nShall be returned when the request has been processed successfully.\nThe response body shall contain a data structure of type \"ThresholdModifications\".\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"ETag":{"description":"Used to provide the current entity-tag for the selected resource representation. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string"}},"Last-Modified":{"description":"Used to provide a timestamp indicating the date and time at which the server believes the selected resource representation was last modified. It can be sent in \"200 OK\", \"201 Created\" and \"204 No Content\" responses.\n","style":"simple","schema":{"type":"string","format":"date-time"}}},"content":{"application/json":{"schema":{"description":"This type represents modifications to a threshold.\nNOTE:\tAt least one of the attributes defined in this type shall be present in request bodies.\n","type":"object","oneOf":[{"required":["callbackUri"]},{"required":["authentication"]}],"properties":{"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE 1 : The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between\n subscriptions. The value of clientPassword should be generated by a random process.\n* NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT which uses mutual authentication based on X.509 certificates, this mode which uses client password to authenticate may be used in the access token request\n toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations\n (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details.\n* NOTE 3: The following values that were included up to version 3.4.1 of the present document have been removed: \"BASIC\" (to signal the use of the basic HTTP authentication) has been removed because it is insecure.\n \"TLS_CERT\" to signal an alternative non-token based authorization method using TLS certificates has been\n removed because the method is no longer supported.\n* NOTE 4: The client certificate is established by means outside the scope of the present document.\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values (see note 3): * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use\n an OAuth 2.0 token, obtained using the client\n credentials grant type after authenticating\n using client identifier and client password\n towards the token endpoint.\n* OAUTH2_CLIENT_CERT: In every HTTP request to the notification endpoint, use an\n OAuth 2.0 token, obtained using the client\n credentials grant type after mutually\n authenticating using client identifier and X.509\n certificates towards the token endpoint.\n","type":"array","items":{"type":"string","enum":["OAUTH2_CLIENT_CREDENTIALS","OAUTH2_CLIENT_CERT"]}},"paramsOauth2ClientCert":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CERT.\nShall be present if authType is \"OAUTH2_CLIENT_CERT\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\n","type":"object","required":["clientId","certificateRef","tokenEndpoint"],"properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint.\n","type":"string"},"certificateRef":{"description":"Fingerprint of the client certificate. The hash function shall use SHA256 or higher. See note 4.\n","type":"string","required":["type","value"],"properties":{"type":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"value":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS.\nShall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\nSee note 2.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"clientPassword":{"description":"Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualThreshold.Patch.412":{"description":"412 Precondition Failed\n\nShall be returned upon the following error: A\nprecondition given in an HTTP request header is\nnot fulfilled.\nTypically, this is due to an ETag mismatch,\nindicating that the resource was modified by\nanother entity.\nThe response body should contain a\nProblemDetails structure, in which the \"detail\"\nattribute should convey more information about the\nerror\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualThreshold.Patch.422":{"description":"422 Unprocessable Content\n\nShall be returned upon the following error: The\ncontent type of the message content is supported and\nthe message content of a request contains\nsyntactically correct data but the data cannot be\nprocessed.\nThe general cause for this error and its handling is\nspecified in clause 6.4 of ETSI\nGS NFV-SOL 013 [8], including rules for the\npresence of the response body.\nSpecifically in case of this resource, the response\ncode 422 shall also be returned if the VNFM has\ntested the Notification endpoint as described in\nclause 6.4.9.3.2 and the test has failed.\nIn this case, the \"detail\" attribute in the\n\"ProblemDetails\" structure shall convey more\ninformation about the error\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualThreshold.Delete.200":{"description":"204 NO CONTENT\n\nThe threshold was deleted successfully.\nThe response body shall be empty.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}}}}} diff --git a/v5.3.1/SOL003-VNFPerformanceManagement-API.yaml b/v5.3.1/SOL003-VNFPerformanceManagement-API.yaml new file mode 100644 index 00000000..60af5e2a --- /dev/null +++ b/v5.3.1/SOL003-VNFPerformanceManagement-API.yaml @@ -0,0 +1,15648 @@ +openapi: 3.0.2 +info: + title: SOL003 - VNF Performance Management interface + description: | + SOL003 - VNF Performance Management interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '2.13.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 003 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf +servers: + - url: 'http://127.0.0.1/vnfpm/v2' + - url: 'https://127.0.0.1/vnfpm/v2' +paths: + /api-versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /pm_jobs: + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + post: + description: | + The POST method creates a PM job. See clause 6.4.2.3.1. + parameters: + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/CreatePmJobRequest' + responses: + '201': + $ref: '#/components/responses/PmJobs.Post.201' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/PmJobs.Post.422' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + get: + description: > + The API consumer can use this method to retrieve information about PM + jobs. See clause 6.4.2.3.2. + parameters: + - $ref: '#/components/parameters/filter_pm_jobs' + - name: all_fields + description: > + Include all complex attributes in the response. See clause 5.3 of + ETSI GS NFV-SOL 013 [8] for details. The VNFM shall support this + parameter. + in: query + required: false + schema: + type: string + - name: fields + description: > + Complex attributes to be included into the response. See clause 5.3 + of ETSI GS NFV-SOL 013 [8] for details. The VNFM should support this + parameter. + in: query + required: false + schema: + type: string + - name: exclude_fields + description: > + Complex attributes to be excluded from the response. See clause 5.3 + of ETSI GS NFV-SOL 013 [8] for details. The VNFM should support this + parameter. + in: query + required: false + schema: + type: string + - $ref: '#/components/parameters/exclude_default_pm_jobs' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this + resource. + in: query + required: false + schema: + type: string + responses: + '200': + $ref: '#/components/responses/PmJobs.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/pm_jobs/{pmJobId}': + parameters: + - $ref: '#/components/parameters/PmJobId' + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + get: + description: > + The API consumer can use this method for reading an individual PM job. + See clause 6.4.3.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualPmJob.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method allows to modify an "Individual PM job" resource. See clause + 6.4.3.3.4. + parameters: + - name: If-Unmodified-Since + description: > + Used to make the request method conditional on the selected + resource representation's last modification date being earlier than + or equal to the date provided in the field-value. If the condition + is not met, the request fails with a "412 Precondition Failed" + response. + required: false + in: header + schema: + type: string + format: date-time + - name: If-Match + description: > + Used to make the request method conditional on the recipient origin + server either having at least one current representation of the + target resource, when the field-value is "*", or having a current + representation of the target resource that has an entity-tag + matching a member of the list of entity-tags provided in the + field-value. If the condition is not met, the request fails with a + "412 Precondition Failed" response. + required: false + in: header + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/PmJobModificationRequest' + responses: + '200': + $ref: '#/components/responses/IndividualPmJob.Patch.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/IndividualPmJob.Patch.412' + '422': + $ref: '#/components/responses/IndividualPmJob.Patch.422' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: | + This method terminates an individual PM job. See clause 6.4.3.3.5. + responses: + '204': + $ref: '#/components/responses/IndividualPmJob.Delete.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/pm_jobs/{pmJobId}/reports/{reportId}': + parameters: + - $ref: '#/components/parameters/PmJobId' + - $ref: '#/components/parameters/ReportId' + get: + description: > + The API consumer can use this method for reading an individual + performance report. See clause 6.4.4.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualPerformanceReport.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /thresholds: + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + post: + description: > + The POST method can be used by the API consumer to create a threshold. + See clause 6.4.5.3.1. + parameters: + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/CreateThresholdRequest' + responses: + '201': + $ref: '#/components/responses/Thresholds.Post.201' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/Thresholds.Post.422' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + get: + description: > + The API consumer can use this method to query information about + thresholds. See clause 6.4.5.3.2. + parameters: + - $ref: '#/components/parameters/filter_thresholds' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this + resource. + in: query + required: false + schema: + type: string + responses: + '200': + $ref: '#/components/responses/Thresholds.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/thresholds/{thresholdId}': + parameters: + - $ref: '#/components/parameters/ThresholdId' + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + get: + description: > + The API consumer can use this method for reading an individual + threshold. See clause 6.4.6.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualThreshold.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method allows to modify an "Individual threshold" resource. See + clause 6.4.6.3.4. + parameters: + - name: If-Unmodified-Since + description: > + Used to make the request method conditional on the selected + resource representation's last modification date being earlier than + or equal to the date provided in the field-value. If the condition + is not met, the request fails with a "412 Precondition Failed" + response. + required: false + in: header + schema: + type: string + format: date-time + - name: If-Match + description: > + Used to make the request method conditional on the recipient origin + server either having at least one current representation of the + target resource, when the field-value is "*", or having a current + representation of the target resource that has an entity-tag + matching a member of the list of entity-tags provided in the + field-value. If the condition is not met, the request fails with a + "412 Precondition Failed" response. + required: false + in: header + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/ThresholdModificationRequest' + responses: + '200': + $ref: '#/components/responses/IndividualThreshold.Patch.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/IndividualThreshold.Patch.412' + '422': + $ref: '#/components/responses/IndividualThreshold.Patch.422' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: | + This method allows to delete a threshold. See clause 6.4.6.3.5. + responses: + '204': + $ref: '#/components/responses/IndividualThreshold.Delete.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + parameters: + filter_pm_jobs: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part + of the URI query string. The NFVO may supply this parameter. All + attribute names that appear in the PmJob and in data types referenced + from it shall be supported by the VNFM in the filter expression. + in: query + required: false + schema: + type: string + exclude_default_pm_jobs: + name: exclude_default + in: query + description: >- + Indicates to exclude the following complex attributes from the response. + See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM shall + support this parameter. The following attributes shall be excluded from + the PmJob structure in the response body if this parameter is provided, + or none of the parameters "all_fields," "fields", "exclude_fields", + "exclude_default" are provided: + - reports + required: false + schema: + type: string + filter_thresholds: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part + of the URI query string. The NFVO may supply this parameter. All + attribute names that appear in the Thresholds data type and in data + types referenced from it shall be supported by the VNFM in the filter + expression + in: query + required: false + schema: + type: string + PmJobId: + name: pmJobId + in: path + description: | + Identifier of the PM job. + This identifier can be retrieved from the resource referenced by the + "Location" HTTP header in the response to a POST request creating a + new "Individual PM job" resource. It can also be retrieved from the "id" + attribute in the message content of that response. + required: true + style: simple + explode: false + schema: + type: string + ReportId: + name: reportId + in: path + description: | + Identifier of the performance report. + required: true + style: simple + explode: false + schema: + type: string + ThresholdId: + name: thresholdId + in: path + description: > + Identifier of the threshold. + + This identifier can be retrieved from the resource referenced by the + + "Location" HTTP header in the response to a POST request creating a + + new "Individual threshold" resource. It can also be retrieved from the + "id" + + attribute in the message content of that response. + required: true + style: simple + explode: false + schema: + type: string + requestBodies: + CreatePmJobRequest: + description: The VNF creation parameters + content: + application/json: + schema: + description: | + This type represents a request to create a PM job. + type: object + required: + - objectType + - objectInstanceIds + - criteria + - callbackUri + properties: + objectType: + description: > + Type of the measured object. The applicable measured object + type for a measurement is defined in clause 7.2 of ETSI GS + NFV-IFA 027. + type: string + objectInstanceIds: + description: > + Identifiers of the measured object instances for which + performance information is requested to be collected. + type: array + items: + description: | + An identifier with the intention of being globally unique. + type: string + subObjectInstanceIds: + description: > + Identifiers of the sub-object instances of the measured object + instance for which performance information is requested to be + collected. May be present if a sub-object is defined in clause + 6.2 of ETSI GS NFV-IFA 027for the related measured object + type. If this attribute is present, the cardinality of the + "objectInstanceIds" attribute shall be 1. If this attribute is + absent and a sub-object is defined in clause 6.2 of ETSI GS + NFV IFA 027 for the related measured object type, measurements + will be taken for all sub-object instances of the measured + object instance. + type: array + items: + description: > + An identifier that is unique for the respective type within + a VNF instance, but may not be globally unique. + type: string + criteria: + description: "This type represents collection criteria for PM jobs.\nNOTE 1:\tAt the end of each reportingPeriod, the API producer will inform the API consumer about availability of the \n performance data collected for each completed collection period during this reportingPeriod. \n The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance \n data for the collection periods within one reporting period are reported together.\nNOTE 2:\tIn particular when choosing short collection and reporting periods, the number of PM jobs that can be supported \n depends on the capability of the producing entity.\n" + type: object + required: + - collectionPeriod + - reportingPeriod + properties: + performanceMetric: + description: > + This defines the types of performance metrics for the + specified object instances. Valid values are specified as + "Measurement Name" values in clause 7.2 of ETSI GS NFV-IFA + 027. At least one of the two attributes (performance + metric or group) shall be present. + type: array + items: + type: string + performanceMetricGroup: + description: > + Group of performance metrics. A metric group is a + pre-defined list of metrics, known to the API producer + that it can decompose to individual metrics. Valid values + are specified as "Measurement Group" values in clause 7.2 + of ETSI GS NFV-IFA 027. At least one of the two attributes + (performance metric or group) shall be present. + type: array + items: + type: string + collectionPeriod: + description: > + SSpecifies the periodicity at which the API producer will + collect performance information. The unit shall be + seconds. See notes 1 and 2. + type: integer + minimum: 0 + maximum: 1024 + reportingPeriod: + description: > + Specifies the periodicity at which the API producer will + report to the API consumer about performance information. + The unit shall be seconds. See notes 1 and 2. + type: integer + minimum: 0 + maximum: 1024 + reportingBoundary: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + authentication: + description: > + * NOTE 1 : The clientId and clientPassword passed in a + subscription shall not be the same as the clientId and + clientPassword that are used to obtain authorization for API requests. Client credentials may differ between + subscriptions. The value of clientPassword should be generated by a random process. + * NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT + which uses mutual authentication based on X.509 + certificates, this mode which uses client password to authenticate may be used in the access token request + toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations + (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details. + * NOTE 3: The following values that were included up to + version 3.4.1 of the present document have been removed: + "BASIC" (to signal the use of the basic HTTP authentication) has been removed because it is insecure. + "TLS_CERT" to signal an alternative non-token based authorization method using TLS certificates has been + removed because the method is no longer supported. + * NOTE 4: The client certificate is established by means + outside the scope of the present document. + type: object + required: + - authType + properties: + authType: + description: > + Defines the types of Authentication / Authorization which + the API consumer is willing to accept when receiving a + notification. Permitted values (see note 3): * + OAUTH2_CLIENT_CREDENTIALS: In every + HTTP request to the notification endpoint, use + an OAuth 2.0 token, obtained using the client + credentials grant type after authenticating + using client identifier and client password + towards the token endpoint. + * OAUTH2_CLIENT_CERT: In every HTTP + request to the notification endpoint, use an + OAuth 2.0 token, obtained using the client + credentials grant type after mutually + authenticating using client identifier and X.509 + certificates towards the token endpoint. + type: array + items: + type: string + enum: + - OAUTH2_CLIENT_CREDENTIALS + - OAUTH2_CLIENT_CERT + paramsOauth2ClientCert: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CERT. + + Shall be present if authType is "OAUTH2_CLIENT_CERT" and + the contained information has not been provisioned out of + band. + + Shall be absent otherwise. + type: object + required: + - clientId + - certificateRef + - tokenEndpoint + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. + type: string + certificateRef: + description: > + Fingerprint of the client certificate. The hash + function shall use SHA256 or higher. See note 4. + type: string + required: + - type + - value + properties: + type: + description: | + A string defined in IETF RFC 8259. + type: string + value: + description: | + A string defined in IETF RFC 8259. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + paramsOauth2ClientCredentials: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CREDENTIALS. + + Shall be present if authType is + "OAUTH2_CLIENT_CREDENTIALS" and the contained information + has not been provisioned out of band. + + Shall be absent otherwise. + + See note 2. + type: object + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. Shall be present if it has not been + provisioned out of band. See note 1. + type: string + clientPassword: + description: > + Client password to be used in the access token request + of the OAuth 2.0 client credentials grant type. Shall + be present if it has not been provisioned out of band. + See note 1. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + PmJobModificationRequest: + description: Parameters for the PM job modification + content: + application/merge-patch+json: + schema: + description: "This type represents modifications to a PM job.\nNOTE:\tAt least one of the attributes defined in this type shall be present in request bodies.\n" + type: object + oneOf: + - required: + - callbackUri + - required: + - authentication + properties: + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + authentication: + description: > + * NOTE 1 : The clientId and clientPassword passed in a + subscription shall not be the same as the clientId and + clientPassword that are used to obtain authorization for API requests. Client credentials may differ between + subscriptions. The value of clientPassword should be generated by a random process. + * NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT + which uses mutual authentication based on X.509 + certificates, this mode which uses client password to authenticate may be used in the access token request + toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations + (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details. + * NOTE 3: The following values that were included up to + version 3.4.1 of the present document have been removed: + "BASIC" (to signal the use of the basic HTTP authentication) has been removed because it is insecure. + "TLS_CERT" to signal an alternative non-token based authorization method using TLS certificates has been + removed because the method is no longer supported. + * NOTE 4: The client certificate is established by means + outside the scope of the present document. + type: object + required: + - authType + properties: + authType: + description: > + Defines the types of Authentication / Authorization which + the API consumer is willing to accept when receiving a + notification. Permitted values (see note 3): * + OAUTH2_CLIENT_CREDENTIALS: In every + HTTP request to the notification endpoint, use + an OAuth 2.0 token, obtained using the client + credentials grant type after authenticating + using client identifier and client password + towards the token endpoint. + * OAUTH2_CLIENT_CERT: In every HTTP + request to the notification endpoint, use an + OAuth 2.0 token, obtained using the client + credentials grant type after mutually + authenticating using client identifier and X.509 + certificates towards the token endpoint. + type: array + items: + type: string + enum: + - OAUTH2_CLIENT_CREDENTIALS + - OAUTH2_CLIENT_CERT + paramsOauth2ClientCert: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CERT. + + Shall be present if authType is "OAUTH2_CLIENT_CERT" and + the contained information has not been provisioned out of + band. + + Shall be absent otherwise. + type: object + required: + - clientId + - certificateRef + - tokenEndpoint + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. + type: string + certificateRef: + description: > + Fingerprint of the client certificate. The hash + function shall use SHA256 or higher. See note 4. + type: string + required: + - type + - value + properties: + type: + description: | + A string defined in IETF RFC 8259. + type: string + value: + description: | + A string defined in IETF RFC 8259. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + paramsOauth2ClientCredentials: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CREDENTIALS. + + Shall be present if authType is + "OAUTH2_CLIENT_CREDENTIALS" and the contained information + has not been provisioned out of band. + + Shall be absent otherwise. + + See note 2. + type: object + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. Shall be present if it has not been + provisioned out of band. See note 1. + type: string + clientPassword: + description: > + Client password to be used in the access token request + of the OAuth 2.0 client credentials grant type. Shall + be present if it has not been provisioned out of band. + See note 1. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + CreateThresholdRequest: + description: Request parameters to create a threshold resource. + content: + application/json: + schema: + description: | + This type represents a request to create a threshold. + type: object + required: + - objectType + - objectInstanceId + - criteria + - callbackUri + properties: + objectType: + description: > + Type of the measured object. The applicable measured object + type for a measurement is defined in clause 7.2 of ETSI GS + NFV-IFA 027. + type: string + objectInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + subObjectInstanceIds: + description: > + Identifiers of the sub-object instances of the measured object + instance associated with this threshold. May be present if a + sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for + the related measured object type. If this attribute is absent + and a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA + 027 for the measured object type, measurements will be taken + for all sub-object instances of the measured object instance. + type: array + items: + description: > + An identifier that is unique for the respective type within + a VNF instance, but may not be globally unique. + type: string + criteria: + description: "This type represents criteria that define a threshold.\nNOTE 1:\tIn the present document, simple thresholds are defined. The definition of additional threshold types is left for \n future specification.\nNOTE 2:\tThe hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create \n a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or \n reject the request). \n" + type: object + required: + - performanceMetric + - thresholdType + properties: + performanceMetric: + description: > + Defines the performance metric associated with the + threshold. Valid values are specified as "Measurement + Name" values in clause 7.2 of ETSI GS NFV-IFA 027. + type: string + thresholdType: + description: "Type of threshold. This attribute determines which other attributes are present in the data structure.\nPermitted values: -\tSIMPLE: Single-valued static threshold. See note 1.\n" + type: string + enum: + - SIMPLE + simpleThresholdDetails: + description: > + Details of a simple threshold. Shall be present if + thresholdType="SIMPLE". + type: object + required: + - thresholdValue + - hysteresis + properties: + thresholdValue: + description: > + The threshold value. Shall be represented as a + floating point number. + type: number + format: float + hysteresis: + description: > + The hysteresis of the threshold. Shall be represented + as a non-negative floating point number. + + A notification with crossing direction "UP" will be + generated if the measured value reaches or exceeds + "thresholdValue" + "hysteresis". A notification with + crossing direction "DOWN" will be generated if the + measured value reaches or undercuts "thresholdValue" - + "hysteresis". See note 2. + type: number + minimum: 0 + maximum: 1024 + format: float + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + authentication: + description: > + * NOTE 1 : The clientId and clientPassword passed in a + subscription shall not be the same as the clientId and + clientPassword that are used to obtain authorization for API requests. Client credentials may differ between + subscriptions. The value of clientPassword should be generated by a random process. + * NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT + which uses mutual authentication based on X.509 + certificates, this mode which uses client password to authenticate may be used in the access token request + toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations + (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details. + * NOTE 3: The following values that were included up to + version 3.4.1 of the present document have been removed: + "BASIC" (to signal the use of the basic HTTP authentication) has been removed because it is insecure. + "TLS_CERT" to signal an alternative non-token based authorization method using TLS certificates has been + removed because the method is no longer supported. + * NOTE 4: The client certificate is established by means + outside the scope of the present document. + type: object + required: + - authType + properties: + authType: + description: > + Defines the types of Authentication / Authorization which + the API consumer is willing to accept when receiving a + notification. Permitted values (see note 3): * + OAUTH2_CLIENT_CREDENTIALS: In every + HTTP request to the notification endpoint, use + an OAuth 2.0 token, obtained using the client + credentials grant type after authenticating + using client identifier and client password + towards the token endpoint. + * OAUTH2_CLIENT_CERT: In every HTTP + request to the notification endpoint, use an + OAuth 2.0 token, obtained using the client + credentials grant type after mutually + authenticating using client identifier and X.509 + certificates towards the token endpoint. + type: array + items: + type: string + enum: + - OAUTH2_CLIENT_CREDENTIALS + - OAUTH2_CLIENT_CERT + paramsOauth2ClientCert: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CERT. + + Shall be present if authType is "OAUTH2_CLIENT_CERT" and + the contained information has not been provisioned out of + band. + + Shall be absent otherwise. + type: object + required: + - clientId + - certificateRef + - tokenEndpoint + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. + type: string + certificateRef: + description: > + Fingerprint of the client certificate. The hash + function shall use SHA256 or higher. See note 4. + type: string + required: + - type + - value + properties: + type: + description: | + A string defined in IETF RFC 8259. + type: string + value: + description: | + A string defined in IETF RFC 8259. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + paramsOauth2ClientCredentials: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CREDENTIALS. + + Shall be present if authType is + "OAUTH2_CLIENT_CREDENTIALS" and the contained information + has not been provisioned out of band. + + Shall be absent otherwise. + + See note 2. + type: object + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. Shall be present if it has not been + provisioned out of band. See note 1. + type: string + clientPassword: + description: > + Client password to be used in the access token request + of the OAuth 2.0 client credentials grant type. Shall + be present if it has not been provisioned out of band. + See note 1. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + ThresholdModificationRequest: + description: Parameters for the threshold modification. + content: + application/merge-patch+json: + schema: + description: "This type represents modifications to a threshold.\nNOTE:\tAt least one of the attributes defined in this type shall be present in request bodies.\n" + type: object + oneOf: + - required: + - callbackUri + - required: + - authentication + properties: + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + authentication: + description: > + * NOTE 1 : The clientId and clientPassword passed in a + subscription shall not be the same as the clientId and + clientPassword that are used to obtain authorization for API requests. Client credentials may differ between + subscriptions. The value of clientPassword should be generated by a random process. + * NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT + which uses mutual authentication based on X.509 + certificates, this mode which uses client password to authenticate may be used in the access token request + toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations + (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details. + * NOTE 3: The following values that were included up to + version 3.4.1 of the present document have been removed: + "BASIC" (to signal the use of the basic HTTP authentication) has been removed because it is insecure. + "TLS_CERT" to signal an alternative non-token based authorization method using TLS certificates has been + removed because the method is no longer supported. + * NOTE 4: The client certificate is established by means + outside the scope of the present document. + type: object + required: + - authType + properties: + authType: + description: > + Defines the types of Authentication / Authorization which + the API consumer is willing to accept when receiving a + notification. Permitted values (see note 3): * + OAUTH2_CLIENT_CREDENTIALS: In every + HTTP request to the notification endpoint, use + an OAuth 2.0 token, obtained using the client + credentials grant type after authenticating + using client identifier and client password + towards the token endpoint. + * OAUTH2_CLIENT_CERT: In every HTTP + request to the notification endpoint, use an + OAuth 2.0 token, obtained using the client + credentials grant type after mutually + authenticating using client identifier and X.509 + certificates towards the token endpoint. + type: array + items: + type: string + enum: + - OAUTH2_CLIENT_CREDENTIALS + - OAUTH2_CLIENT_CERT + paramsOauth2ClientCert: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CERT. + + Shall be present if authType is "OAUTH2_CLIENT_CERT" and + the contained information has not been provisioned out of + band. + + Shall be absent otherwise. + type: object + required: + - clientId + - certificateRef + - tokenEndpoint + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. + type: string + certificateRef: + description: > + Fingerprint of the client certificate. The hash + function shall use SHA256 or higher. See note 4. + type: string + required: + - type + - value + properties: + type: + description: | + A string defined in IETF RFC 8259. + type: string + value: + description: | + A string defined in IETF RFC 8259. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + paramsOauth2ClientCredentials: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CREDENTIALS. + + Shall be present if authType is + "OAUTH2_CLIENT_CREDENTIALS" and the contained information + has not been provisioned out of band. + + Shall be absent otherwise. + + See note 2. + type: object + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. Shall be present if it has not been + provisioned out of band. See note 1. + type: string + clientPassword: + description: > + Client password to be used in the access token request + of the OAuth 2.0 client credentials grant type. Shall + be present if it has not been provisioned out of band. + See note 1. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + responses: + PmJobs.Post.201: + description: > + 201 CREATED + + + Shall be returned when the PM job has been created successfully. + + The response body shall contain a representation of the created + "Individual PM job" resource, + + as defined in clause 6.5.2.7. + + The HTTP response shall include a "Location" HTTP header that points to + the created + + "Individual PM job" resource. + headers: + Location: + description: The resource URI of the created PM Job + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: | + This type represents a PM job. + type: object + required: + - id + - objectType + - objectInstanceIds + - criteria + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + objectType: + description: > + Type of the measured object. The applicable measured object + type for a measurement is defined in clause 7.2 of ETSI GS + NFV-IFA 027. + type: string + objectInstanceIds: + description: > + Identifiers of the VNF instances for which performance + information is collected. + type: array + items: + description: | + An identifier with the intention of being globally unique. + type: string + subObjectInstanceIds: + description: > + Identifiers of the sub-object instances of the measured object + instance for which performance information is requested to be + collected. May be present if a sub-object is defined in clause + 6.2 of ETSI GS NFV-IFA 027 for the related measured object + type. If this attribute is present, the cardinality of the + "objectInstanceIds" attribute shall be 1. If this attribute is + absent and a sub-object is defined in clause 6.2 of ETSI GS + NFV IFA 027 for the related measured object type, measurements + will be taken for all sub-object instances of the measured + object instance. + type: array + items: + description: > + An identifier that is unique for the respective type within + a VNF instance, but may not be globally unique. + type: string + criteria: + description: "This type represents collection criteria for PM jobs.\nNOTE 1:\tAt the end of each reportingPeriod, the API producer will inform the API consumer about availability of the \n performance data collected for each completed collection period during this reportingPeriod. \n The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance \n data for the collection periods within one reporting period are reported together.\nNOTE 2:\tIn particular when choosing short collection and reporting periods, the number of PM jobs that can be supported \n depends on the capability of the producing entity.\n" + type: object + required: + - collectionPeriod + - reportingPeriod + properties: + performanceMetric: + description: > + This defines the types of performance metrics for the + specified object instances. Valid values are specified as + "Measurement Name" values in clause 7.2 of ETSI GS NFV-IFA + 027. At least one of the two attributes (performance + metric or group) shall be present. + type: array + items: + type: string + performanceMetricGroup: + description: > + Group of performance metrics. A metric group is a + pre-defined list of metrics, known to the API producer + that it can decompose to individual metrics. Valid values + are specified as "Measurement Group" values in clause 7.2 + of ETSI GS NFV-IFA 027. At least one of the two attributes + (performance metric or group) shall be present. + type: array + items: + type: string + collectionPeriod: + description: > + SSpecifies the periodicity at which the API producer will + collect performance information. The unit shall be + seconds. See notes 1 and 2. + type: integer + minimum: 0 + maximum: 1024 + reportingPeriod: + description: > + Specifies the periodicity at which the API producer will + report to the API consumer about performance information. + The unit shall be seconds. See notes 1 and 2. + type: integer + minimum: 0 + maximum: 1024 + reportingBoundary: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + reports: + description: | + Information about available reports collected by this PM job. + type: object + required: + - href + - readyTime + properties: + href: + description: | + The URI where the report can be obtained. + type: string + format: url + readyTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + expiryTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + fileSize: + description: | + The size of the report file in bytes, if known. + type: integer + minimum: 0 + pmJobConnection: + description: > + An access information and interface information of PM job to + monitor the PM of VNF instance by the VNFM. This can include + for instance certain interface endpoint URI together with + necessary credentials to access it. + type: array + items: + description: > + The MonitoringConnection shall follow the indications + provided. + + * NOTE: The VNFM can be made aware of monitoring connection + information, + including their identifiers to be used by configuration means outside the scope of the + present document (e.g. using relevant NFV-MANO management APIs as defined in + ETSI GS NFV-SOL 009 [i.18]). + type: object + required: + - id + - monitoringType + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + monitoringType: + description: | + Type of monitoring way. + type: string + enum: + - VIM_CISM + - EXTERNAL + - PAAS + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being globally + unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: | + A string defined in IETF RFC 8259. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + objects: + description: > + Links to resources representing the measure object + instances for which performance information is collected. + Shall be present if the measured object instance + information is accessible as a resource. + type: array + items: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + PmJobs.Post.422: + description: | + 422 Unprocessable Content + + Shall be returned upon the following error: The + content type of the message content is supported and + the message content of a request contains syntactically + correct data but the data cannot be processed. + The general cause for this error and its handling is + specified in clause 6.4 of ETSI GS NFV-SOL 013 [8], + including rules for the presence of the response + body. + Specifically in case of this resource, the response + code 422 shall also be returned if the VNFM has + tested the Notification endpoint as described in + clause 6.4.9.3.2 and the test has failed. + In this case, the "detail" attribute in the + "ProblemDetails" structure sh + headers: + Location: + description: The resource URI of the created PM Job + style: simple + explode: false + schema: + type: string + format: url + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + PmJobs.Get.200: + description: > + 200 OK + + + Shall be returned when information about zero or more PM jobs has been + queried successfully. + + The response body shall contain in an array the representations of zero + or more PM jobs, + + as defined in clause 6.5.2.7. + + If the "filter" URI parameter or one of the "all_fields", "fields" (if + supported), "exclude_fields" + + (if supported) or "exclude_default" URI parameters was supplied in the + request, the data in the + + response body shall have been transformed according to the rules + specified in clauses 5.2.2 and 5.3.2 + + of ETSI GS NFV-SOL 013, respectively. + + If the VNFM supports alternative 2 (paging) according to clause 5.4..2.1 + of ETSI GS NFV-SOL 013 + + for this resource, inclusion of the Link HTTP header in this response + shall follow the provisions + + in clause 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: | + This type represents a PM job. + type: object + required: + - id + - objectType + - objectInstanceIds + - criteria + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + objectType: + description: > + Type of the measured object. The applicable measured object + type for a measurement is defined in clause 7.2 of ETSI GS + NFV-IFA 027. + type: string + objectInstanceIds: + description: > + Identifiers of the VNF instances for which performance + information is collected. + type: array + items: + description: | + An identifier with the intention of being globally unique. + type: string + subObjectInstanceIds: + description: > + Identifiers of the sub-object instances of the measured + object instance for which performance information is + requested to be collected. May be present if a sub-object is + defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related + measured object type. If this attribute is present, the + cardinality of the "objectInstanceIds" attribute shall be 1. + If this attribute is absent and a sub-object is defined in + clause 6.2 of ETSI GS NFV IFA 027 for the related measured + object type, measurements will be taken for all sub-object + instances of the measured object instance. + type: array + items: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + criteria: + description: "This type represents collection criteria for PM jobs.\nNOTE 1:\tAt the end of each reportingPeriod, the API producer will inform the API consumer about availability of the \n performance data collected for each completed collection period during this reportingPeriod. \n The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance \n data for the collection periods within one reporting period are reported together.\nNOTE 2:\tIn particular when choosing short collection and reporting periods, the number of PM jobs that can be supported \n depends on the capability of the producing entity.\n" + type: object + required: + - collectionPeriod + - reportingPeriod + properties: + performanceMetric: + description: > + This defines the types of performance metrics for the + specified object instances. Valid values are specified + as "Measurement Name" values in clause 7.2 of ETSI GS + NFV-IFA 027. At least one of the two attributes + (performance metric or group) shall be present. + type: array + items: + type: string + performanceMetricGroup: + description: > + Group of performance metrics. A metric group is a + pre-defined list of metrics, known to the API producer + that it can decompose to individual metrics. Valid + values are specified as "Measurement Group" values in + clause 7.2 of ETSI GS NFV-IFA 027. At least one of the + two attributes (performance metric or group) shall be + present. + type: array + items: + type: string + collectionPeriod: + description: > + SSpecifies the periodicity at which the API producer + will collect performance information. The unit shall be + seconds. See notes 1 and 2. + type: integer + minimum: 0 + maximum: 1024 + reportingPeriod: + description: > + Specifies the periodicity at which the API producer will + report to the API consumer about performance + information. The unit shall be seconds. See notes 1 and + 2. + type: integer + minimum: 0 + maximum: 1024 + reportingBoundary: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + reports: + description: > + Information about available reports collected by this PM + job. + type: object + required: + - href + - readyTime + properties: + href: + description: | + The URI where the report can be obtained. + type: string + format: url + readyTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + expiryTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + fileSize: + description: | + The size of the report file in bytes, if known. + type: integer + minimum: 0 + pmJobConnection: + description: > + An access information and interface information of PM job to + monitor the PM of VNF instance by the VNFM. This can + include for instance certain interface endpoint URI together + with necessary credentials to access it. + type: array + items: + description: > + The MonitoringConnection shall follow the indications + provided. + + * NOTE: The VNFM can be made aware of monitoring + connection information, + including their identifiers to be used by configuration means outside the scope of the + present document (e.g. using relevant NFV-MANO management APIs as defined in + ETSI GS NFV-SOL 009 [i.18]). + type: object + required: + - id + - monitoringType + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + monitoringType: + description: | + Type of monitoring way. + type: string + enum: + - VIM_CISM + - EXTERNAL + - PAAS + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being globally + unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: | + A string defined in IETF RFC 8259. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + objects: + description: > + Links to resources representing the measure object + instances for which performance information is + collected. Shall be present if the measured object + instance information is accessible as a resource. + type: array + items: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualPmJob.Get.200: + description: > + 200 OK + + + Shall be returned when information about an individual PM job has been + read successfully. + + The response body shall contain a representation of the "Individual PM + job" resource, + + as defined in clause 6.5.2.7. + headers: + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: | + This type represents a PM job. + type: object + required: + - id + - objectType + - objectInstanceIds + - criteria + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + objectType: + description: > + Type of the measured object. The applicable measured object + type for a measurement is defined in clause 7.2 of ETSI GS + NFV-IFA 027. + type: string + objectInstanceIds: + description: > + Identifiers of the VNF instances for which performance + information is collected. + type: array + items: + description: | + An identifier with the intention of being globally unique. + type: string + subObjectInstanceIds: + description: > + Identifiers of the sub-object instances of the measured object + instance for which performance information is requested to be + collected. May be present if a sub-object is defined in clause + 6.2 of ETSI GS NFV-IFA 027 for the related measured object + type. If this attribute is present, the cardinality of the + "objectInstanceIds" attribute shall be 1. If this attribute is + absent and a sub-object is defined in clause 6.2 of ETSI GS + NFV IFA 027 for the related measured object type, measurements + will be taken for all sub-object instances of the measured + object instance. + type: array + items: + description: > + An identifier that is unique for the respective type within + a VNF instance, but may not be globally unique. + type: string + criteria: + description: "This type represents collection criteria for PM jobs.\nNOTE 1:\tAt the end of each reportingPeriod, the API producer will inform the API consumer about availability of the \n performance data collected for each completed collection period during this reportingPeriod. \n The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance \n data for the collection periods within one reporting period are reported together.\nNOTE 2:\tIn particular when choosing short collection and reporting periods, the number of PM jobs that can be supported \n depends on the capability of the producing entity.\n" + type: object + required: + - collectionPeriod + - reportingPeriod + properties: + performanceMetric: + description: > + This defines the types of performance metrics for the + specified object instances. Valid values are specified as + "Measurement Name" values in clause 7.2 of ETSI GS NFV-IFA + 027. At least one of the two attributes (performance + metric or group) shall be present. + type: array + items: + type: string + performanceMetricGroup: + description: > + Group of performance metrics. A metric group is a + pre-defined list of metrics, known to the API producer + that it can decompose to individual metrics. Valid values + are specified as "Measurement Group" values in clause 7.2 + of ETSI GS NFV-IFA 027. At least one of the two attributes + (performance metric or group) shall be present. + type: array + items: + type: string + collectionPeriod: + description: > + SSpecifies the periodicity at which the API producer will + collect performance information. The unit shall be + seconds. See notes 1 and 2. + type: integer + minimum: 0 + maximum: 1024 + reportingPeriod: + description: > + Specifies the periodicity at which the API producer will + report to the API consumer about performance information. + The unit shall be seconds. See notes 1 and 2. + type: integer + minimum: 0 + maximum: 1024 + reportingBoundary: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + reports: + description: | + Information about available reports collected by this PM job. + type: object + required: + - href + - readyTime + properties: + href: + description: | + The URI where the report can be obtained. + type: string + format: url + readyTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + expiryTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + fileSize: + description: | + The size of the report file in bytes, if known. + type: integer + minimum: 0 + pmJobConnection: + description: > + An access information and interface information of PM job to + monitor the PM of VNF instance by the VNFM. This can include + for instance certain interface endpoint URI together with + necessary credentials to access it. + type: array + items: + description: > + The MonitoringConnection shall follow the indications + provided. + + * NOTE: The VNFM can be made aware of monitoring connection + information, + including their identifiers to be used by configuration means outside the scope of the + present document (e.g. using relevant NFV-MANO management APIs as defined in + ETSI GS NFV-SOL 009 [i.18]). + type: object + required: + - id + - monitoringType + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + monitoringType: + description: | + Type of monitoring way. + type: string + enum: + - VIM_CISM + - EXTERNAL + - PAAS + vimId: + description: > + An identifier with the intention of being globally + unique. + type: string + paasServiceId: + description: > + An identifier with the intention of being globally + unique. + type: string + interfaceInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + accessInfo: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + extra: + description: | + A string defined in IETF RFC 8259. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + objects: + description: > + Links to resources representing the measure object + instances for which performance information is collected. + Shall be present if the measured object instance + information is accessible as a resource. + type: array + items: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualPmJob.Patch.200: + description: > + 200 OK + + + Shall be returned when the request has been processed successfully. + + The response body shall contain a data structure of type + "PmJobModifications". + headers: + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + ETag: + description: > + Used to provide the current entity-tag for the selected resource + representation. It can be sent in "200 OK", "201 Created" and "204 + No Content" responses. + style: simple + schema: + type: string + Last-Modified: + description: > + Used to provide a timestamp indicating the date and time at which + the server believes the selected resource representation was last + modified. It can be sent in "200 OK", "201 Created" and "204 No + Content" responses. + style: simple + schema: + type: string + format: date-time + content: + application/json: + schema: + description: "This type represents modifications to a PM job.\nNOTE:\tAt least one of the attributes defined in this type shall be present in request bodies.\n" + type: object + oneOf: + - required: + - callbackUri + - required: + - authentication + properties: + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + authentication: + description: > + * NOTE 1 : The clientId and clientPassword passed in a + subscription shall not be the same as the clientId and + clientPassword that are used to obtain authorization for API requests. Client credentials may differ between + subscriptions. The value of clientPassword should be generated by a random process. + * NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT + which uses mutual authentication based on X.509 + certificates, this mode which uses client password to authenticate may be used in the access token request + toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations + (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details. + * NOTE 3: The following values that were included up to + version 3.4.1 of the present document have been removed: + "BASIC" (to signal the use of the basic HTTP authentication) has been removed because it is insecure. + "TLS_CERT" to signal an alternative non-token based authorization method using TLS certificates has been + removed because the method is no longer supported. + * NOTE 4: The client certificate is established by means + outside the scope of the present document. + type: object + required: + - authType + properties: + authType: + description: > + Defines the types of Authentication / Authorization which + the API consumer is willing to accept when receiving a + notification. Permitted values (see note 3): * + OAUTH2_CLIENT_CREDENTIALS: In every + HTTP request to the notification endpoint, use + an OAuth 2.0 token, obtained using the client + credentials grant type after authenticating + using client identifier and client password + towards the token endpoint. + * OAUTH2_CLIENT_CERT: In every HTTP + request to the notification endpoint, use an + OAuth 2.0 token, obtained using the client + credentials grant type after mutually + authenticating using client identifier and X.509 + certificates towards the token endpoint. + type: array + items: + type: string + enum: + - OAUTH2_CLIENT_CREDENTIALS + - OAUTH2_CLIENT_CERT + paramsOauth2ClientCert: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CERT. + + Shall be present if authType is "OAUTH2_CLIENT_CERT" and + the contained information has not been provisioned out of + band. + + Shall be absent otherwise. + type: object + required: + - clientId + - certificateRef + - tokenEndpoint + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. + type: string + certificateRef: + description: > + Fingerprint of the client certificate. The hash + function shall use SHA256 or higher. See note 4. + type: string + required: + - type + - value + properties: + type: + description: | + A string defined in IETF RFC 8259. + type: string + value: + description: | + A string defined in IETF RFC 8259. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + paramsOauth2ClientCredentials: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CREDENTIALS. + + Shall be present if authType is + "OAUTH2_CLIENT_CREDENTIALS" and the contained information + has not been provisioned out of band. + + Shall be absent otherwise. + + See note 2. + type: object + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. Shall be present if it has not been + provisioned out of band. See note 1. + type: string + clientPassword: + description: > + Client password to be used in the access token request + of the OAuth 2.0 client credentials grant type. Shall + be present if it has not been provisioned out of band. + See note 1. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualPmJob.Patch.412: + description: | + 412 Precondition Failed + + Shall be returned upon the following error: A + precondition given in an HTTP request header is not + fulfilled. + Typically, this is due to an ETag mismatch, indicating + that the resource was modified by another entity. + The response body should contain a ProblemDetails + structure, in which the "detail" attribute should convey + more information about the error. + headers: + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualPmJob.Patch.422: + description: | + 422 Unprocessable Content + + Shall be returned upon the following error: The + content type of the message content is supported and the + message content of a request contains syntactically + correct data but the data cannot be processed. + The general cause for this error and its handling is + specified in clause 6.4 of ETSI GS NFV-SOL 013 [8], + including rules for the presence of the response body. + Specifically in case of this resource, the response + code 422 shall also be returned if the VNFM has + tested the Notification endpoint as described in + clause 6.4.9.3.2 and the test has failed. + In this case, the "detail" attribute in the + "ProblemDetails" structure shall convey more + information about the error. + headers: + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualPmJob.Delete.200: + description: | + 204 NO CONTENT + + Shall be returned when the PM job has been deleted successfully. + The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualPerformanceReport.Get.200: + description: > + 200 OK + + + Shall be returned when information of an individual performance report + has been read successfully. + + The response body shall contain a representation of the "Individual + performance report" resource, + + as defined in clause 6.5.2.10. + headers: + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: "This type defines the format of a performance report provided by the VNFM to the NFVO as a result of collecting performance information as part of a PM job.\nNOTE:\tThe sub-object allows to structure the measured object but is not to be confused with sub-counters which allow \n to structure the measurement value.\n\nEXAMPLE:\n Measured object: VnfInstanceXYZ\n Sub-object: VnfcInstance1\n Measurement: vCPU_utilization\n Sub-counters: vCPU utilization of each of the vCPUs of VnfcInstance1 (vCPU utilization.vCPU1, vCPU_utilization.vCPU2, etc.).\n" + type: object + required: + - entries + properties: + entries: + description: > + List of performance information entries. Each performance + report entry is for a given metric of a given object (i.e. VNF + instance), but can include multiple collected values. + type: array + items: + type: object + required: + - objectType + - objectInstanceId + - performanceMetric + - performanceValue + properties: + objectType: + description: > + Type of the measured object. The applicable measured + object type for a measurement is defined in clause 7.2 + of ETSI GS NFV-IFA 027. + type: string + objectInstanceId: + description: > + An identifier with the intention of being globally + unique. + type: string + subObjectInstanceId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + performanceMetric: + description: > + Name of the metric collected. This attribute shall + contain the related "Measurement Name" value as defined + in clause 7.2 of ETSI GS NFV-IFA 027. + type: string + performanceValues: + description: | + List of performance values with associated timestamp. + type: array + items: + type: object + required: + - timeStamp + - value + properties: + timeStamp: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + value: + description: > + Value of the metric collected. The type of this + attribute shall correspond to the related + "Measurement Unit" as defined in clause 7.2. of + ETSI GS NFV-IFA 027. + type: object + context: + description: > + This type represents a list of key-value pairs. + The order of the pairs in the list is not + significant. In JSON, a set of keyvalue pairs is + represented as an object. It shall comply with the + provisions defined in clause 4 of IETF RFC 8259. + In the following example, a list of key-value + pairs with four keys ("aString", "aNumber", + "anArray" and "anObject") is provided to + illustrate that the values associated with + different keys can be of different type. + type: object + Thresholds.Post.201: + description: > + 201 CREATED + + + Shall be returned when a threshold has been created successfully. + + The response body shall contain a representation of the created + "Individual threshold" resource, + + as defined in clause 6.5.2.9. + + The HTTP response shall include a "Location" HTTP header that contains + the resource URI of the + + created threshold resource. + headers: + Location: + description: TThe resource URI of the created VNF instance + style: simple + explode: false + schema: + type: string + format: url + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: | + This type represents a threshold. + type: object + required: + - id + - objectType + - objectInstanceId + - criteria + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + objectType: + description: > + Type of the measured object. The applicable measured object + type for a measurement is defined in clause 7.2 of ETSI GS + NFV-IFA 027. + type: string + objectInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + subObjectInstanceIds: + description: > + Identifiers of the sub-object instances of the measured object + instance associated with the threshold. May be present if a + sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for + the related measurement type. If this attribute is absent and + a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 + for the related measured object type, measurements will be + taken for all sub-object instances of the measured object + instance. + type: array + items: + description: > + An identifier that is unique for the respective type within + a VNF instance, but may not be globally unique. + type: string + criteria: + description: "This type represents criteria that define a threshold.\nNOTE 1:\tIn the present document, simple thresholds are defined. The definition of additional threshold types is left for \n future specification.\nNOTE 2:\tThe hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create \n a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or \n reject the request). \n" + type: object + required: + - performanceMetric + - thresholdType + properties: + performanceMetric: + description: > + Defines the performance metric associated with the + threshold. Valid values are specified as "Measurement + Name" values in clause 7.2 of ETSI GS NFV-IFA 027. + type: string + thresholdType: + description: "Type of threshold. This attribute determines which other attributes are present in the data structure.\nPermitted values: -\tSIMPLE: Single-valued static threshold. See note 1.\n" + type: string + enum: + - SIMPLE + simpleThresholdDetails: + description: > + Details of a simple threshold. Shall be present if + thresholdType="SIMPLE". + type: object + required: + - thresholdValue + - hysteresis + properties: + thresholdValue: + description: > + The threshold value. Shall be represented as a + floating point number. + type: number + format: float + hysteresis: + description: > + The hysteresis of the threshold. Shall be represented + as a non-negative floating point number. + + A notification with crossing direction "UP" will be + generated if the measured value reaches or exceeds + "thresholdValue" + "hysteresis". A notification with + crossing direction "DOWN" will be generated if the + measured value reaches or undercuts "thresholdValue" - + "hysteresis". See note 2. + type: number + minimum: 0 + maximum: 1024 + format: float + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + object: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + Thresholds.Post.422: + description: | + 422 Unprocessable Content + + Shall be returned upon the following error: The + content type of the message content is supported and + the message content of a request contains + syntactically correct data but the data cannot be + processed. + The general cause for this error and its handling is + specified in clause 6.4 of ETSI + GS NFV-SOL 013 [8], including rules for the + presence of the response body. + Specifically in case of this resource, the response + code 422 shall also be returned if the VNFM has + tested the Notification endpoint as described in + clause 6.4.9.3.2 and the test has failed. + In this case, the "detail" attribute in the + "ProblemDetails" structure shall convey more + information about the error + headers: + Location: + description: TThe resource URI of the created VNF instance + style: simple + explode: false + schema: + type: string + format: url + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + Thresholds.Get.200: + description: > + 200 OK + + + Shall be returned when information about zero or more thresholds has + been queried successfully. + + If the "filter" URI parameter was supplied in the request, the data in + the response body shall have + + been transformed according to the rules specified in clause 5.2.2 of + ETSI GS NFV-SOL 013. + + The response body shall contain in an array the representations of zero + or more thresholds, + + as defined in clause 6.5.2.9. + + If the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 + of ETSI GS NFV-SOL 013 + + for this resource, inclusion of the Link HTTP header in this response + shall follow the provisions + + in clause 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + Location: + description: The resource URI of the created VNF instance + style: simple + explode: false + schema: + type: string + format: url + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: | + This type represents a threshold. + type: object + required: + - id + - objectType + - objectInstanceId + - criteria + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + objectType: + description: > + Type of the measured object. The applicable measured object + type for a measurement is defined in clause 7.2 of ETSI GS + NFV-IFA 027. + type: string + objectInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + subObjectInstanceIds: + description: > + Identifiers of the sub-object instances of the measured + object instance associated with the threshold. May be + present if a sub-object is defined in clause 6.2 of ETSI GS + NFV-IFA 027 for the related measurement type. If this + attribute is absent and a sub-object is defined in clause + 6.2 of ETSI GS NFV-IFA 027 for the related measured object + type, measurements will be taken for all sub-object + instances of the measured object instance. + type: array + items: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + criteria: + description: "This type represents criteria that define a threshold.\nNOTE 1:\tIn the present document, simple thresholds are defined. The definition of additional threshold types is left for \n future specification.\nNOTE 2:\tThe hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create \n a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or \n reject the request). \n" + type: object + required: + - performanceMetric + - thresholdType + properties: + performanceMetric: + description: > + Defines the performance metric associated with the + threshold. Valid values are specified as "Measurement + Name" values in clause 7.2 of ETSI GS NFV-IFA 027. + type: string + thresholdType: + description: "Type of threshold. This attribute determines which other attributes are present in the data structure.\nPermitted values: -\tSIMPLE: Single-valued static threshold. See note 1.\n" + type: string + enum: + - SIMPLE + simpleThresholdDetails: + description: > + Details of a simple threshold. Shall be present if + thresholdType="SIMPLE". + type: object + required: + - thresholdValue + - hysteresis + properties: + thresholdValue: + description: > + The threshold value. Shall be represented as a + floating point number. + type: number + format: float + hysteresis: + description: > + The hysteresis of the threshold. Shall be + represented as a non-negative floating point number. + + A notification with crossing direction "UP" will be + generated if the measured value reaches or exceeds + "thresholdValue" + "hysteresis". A notification with + crossing direction "DOWN" will be generated if the + measured value reaches or undercuts "thresholdValue" + - "hysteresis". See note 2. + type: number + minimum: 0 + maximum: 1024 + format: float + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + object: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualThreshold.Get.200: + description: > + 200 OK + + + Shall be returned when information about an individual threshold has + been read successfully. + + The response body shall contain a representation of the threshold, as + defined in clause 6.5.2.9. + headers: + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + ETag: + description: > + Used to provide the current entity-tag for the selected resource + representation. It can be sent in "200 OK", "201 Created" and "204 + No Content" responses. + style: simple + schema: + type: string + Last-Modified: + description: > + Used to provide a timestamp indicating the date and time at which + the server believes the selected resource representation was last + modified. It can be sent in "200 OK", "201 Created" and "204 No + Content" responses. + style: simple + schema: + type: string + format: date-time + content: + application/json: + schema: + description: | + This type represents a threshold. + type: object + required: + - id + - objectType + - objectInstanceId + - criteria + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + objectType: + description: > + Type of the measured object. The applicable measured object + type for a measurement is defined in clause 7.2 of ETSI GS + NFV-IFA 027. + type: string + objectInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + subObjectInstanceIds: + description: > + Identifiers of the sub-object instances of the measured object + instance associated with the threshold. May be present if a + sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for + the related measurement type. If this attribute is absent and + a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 + for the related measured object type, measurements will be + taken for all sub-object instances of the measured object + instance. + type: array + items: + description: > + An identifier that is unique for the respective type within + a VNF instance, but may not be globally unique. + type: string + criteria: + description: "This type represents criteria that define a threshold.\nNOTE 1:\tIn the present document, simple thresholds are defined. The definition of additional threshold types is left for \n future specification.\nNOTE 2:\tThe hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create \n a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or \n reject the request). \n" + type: object + required: + - performanceMetric + - thresholdType + properties: + performanceMetric: + description: > + Defines the performance metric associated with the + threshold. Valid values are specified as "Measurement + Name" values in clause 7.2 of ETSI GS NFV-IFA 027. + type: string + thresholdType: + description: "Type of threshold. This attribute determines which other attributes are present in the data structure.\nPermitted values: -\tSIMPLE: Single-valued static threshold. See note 1.\n" + type: string + enum: + - SIMPLE + simpleThresholdDetails: + description: > + Details of a simple threshold. Shall be present if + thresholdType="SIMPLE". + type: object + required: + - thresholdValue + - hysteresis + properties: + thresholdValue: + description: > + The threshold value. Shall be represented as a + floating point number. + type: number + format: float + hysteresis: + description: > + The hysteresis of the threshold. Shall be represented + as a non-negative floating point number. + + A notification with crossing direction "UP" will be + generated if the measured value reaches or exceeds + "thresholdValue" + "hysteresis". A notification with + crossing direction "DOWN" will be generated if the + measured value reaches or undercuts "thresholdValue" - + "hysteresis". See note 2. + type: number + minimum: 0 + maximum: 1024 + format: float + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + object: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualThreshold.Patch.200: + description: > + 200 OK + + + Shall be returned when the request has been processed successfully. + + The response body shall contain a data structure of type + "ThresholdModifications". + headers: + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + ETag: + description: > + Used to provide the current entity-tag for the selected resource + representation. It can be sent in "200 OK", "201 Created" and "204 + No Content" responses. + style: simple + schema: + type: string + Last-Modified: + description: > + Used to provide a timestamp indicating the date and time at which + the server believes the selected resource representation was last + modified. It can be sent in "200 OK", "201 Created" and "204 No + Content" responses. + style: simple + schema: + type: string + format: date-time + content: + application/json: + schema: + description: "This type represents modifications to a threshold.\nNOTE:\tAt least one of the attributes defined in this type shall be present in request bodies.\n" + type: object + oneOf: + - required: + - callbackUri + - required: + - authentication + properties: + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + authentication: + description: > + * NOTE 1 : The clientId and clientPassword passed in a + subscription shall not be the same as the clientId and + clientPassword that are used to obtain authorization for API requests. Client credentials may differ between + subscriptions. The value of clientPassword should be generated by a random process. + * NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT + which uses mutual authentication based on X.509 + certificates, this mode which uses client password to authenticate may be used in the access token request + toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations + (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details. + * NOTE 3: The following values that were included up to + version 3.4.1 of the present document have been removed: + "BASIC" (to signal the use of the basic HTTP authentication) has been removed because it is insecure. + "TLS_CERT" to signal an alternative non-token based authorization method using TLS certificates has been + removed because the method is no longer supported. + * NOTE 4: The client certificate is established by means + outside the scope of the present document. + type: object + required: + - authType + properties: + authType: + description: > + Defines the types of Authentication / Authorization which + the API consumer is willing to accept when receiving a + notification. Permitted values (see note 3): * + OAUTH2_CLIENT_CREDENTIALS: In every + HTTP request to the notification endpoint, use + an OAuth 2.0 token, obtained using the client + credentials grant type after authenticating + using client identifier and client password + towards the token endpoint. + * OAUTH2_CLIENT_CERT: In every HTTP + request to the notification endpoint, use an + OAuth 2.0 token, obtained using the client + credentials grant type after mutually + authenticating using client identifier and X.509 + certificates towards the token endpoint. + type: array + items: + type: string + enum: + - OAUTH2_CLIENT_CREDENTIALS + - OAUTH2_CLIENT_CERT + paramsOauth2ClientCert: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CERT. + + Shall be present if authType is "OAUTH2_CLIENT_CERT" and + the contained information has not been provisioned out of + band. + + Shall be absent otherwise. + type: object + required: + - clientId + - certificateRef + - tokenEndpoint + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. + type: string + certificateRef: + description: > + Fingerprint of the client certificate. The hash + function shall use SHA256 or higher. See note 4. + type: string + required: + - type + - value + properties: + type: + description: | + A string defined in IETF RFC 8259. + type: string + value: + description: | + A string defined in IETF RFC 8259. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + paramsOauth2ClientCredentials: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CREDENTIALS. + + Shall be present if authType is + "OAUTH2_CLIENT_CREDENTIALS" and the contained information + has not been provisioned out of band. + + Shall be absent otherwise. + + See note 2. + type: object + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. Shall be present if it has not been + provisioned out of band. See note 1. + type: string + clientPassword: + description: > + Client password to be used in the access token request + of the OAuth 2.0 client credentials grant type. Shall + be present if it has not been provisioned out of band. + See note 1. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualThreshold.Patch.412: + description: | + 412 Precondition Failed + + Shall be returned upon the following error: A + precondition given in an HTTP request header is + not fulfilled. + Typically, this is due to an ETag mismatch, + indicating that the resource was modified by + another entity. + The response body should contain a + ProblemDetails structure, in which the "detail" + attribute should convey more information about the + error + headers: + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualThreshold.Patch.422: + description: | + 422 Unprocessable Content + + Shall be returned upon the following error: The + content type of the message content is supported and + the message content of a request contains + syntactically correct data but the data cannot be + processed. + The general cause for this error and its handling is + specified in clause 6.4 of ETSI + GS NFV-SOL 013 [8], including rules for the + presence of the response body. + Specifically in case of this resource, the response + code 422 shall also be returned if the VNFM has + tested the Notification endpoint as described in + clause 6.4.9.3.2 and the test has failed. + In this case, the "detail" attribute in the + "ProblemDetails" structure shall convey more + information about the error + headers: + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualThreshold.Delete.200: + description: | + 204 NO CONTENT + + The threshold was deleted successfully. + The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + diff --git a/v5.3.1/SOL003-VNFPerformanceManagementNotification-API.json b/v5.3.1/SOL003-VNFPerformanceManagementNotification-API.json new file mode 100644 index 00000000..36adbc20 --- /dev/null +++ b/v5.3.1/SOL003-VNFPerformanceManagementNotification-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL003 - VNF Performance Management Notification interface","description":"SOL003 - VNF Performance Management Notification interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"2.13.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 003 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/callback/v2"},{"url":"https://127.0.0.1/callback/v2"}],"paths":{"/URI_is_provided_by_the_client_when_creating_the_subscription-PerformanceInformationAvailableNotification":{"parameters":[{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"post":{"description":"The POST method delivers a notification regarding a performance management event from API producer to an\nAPI consumer. The API consumer shall have previously created an \"Individual PM job\" resource\nor \"Individual threshold\" resource. See clause 6.4.9.3.1.\n","parameters":[{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/PerformanceInformationAvailableNotification"},"responses":{"204":{"$ref":""},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"get":{"description":"The GET method allows the API producer to test the notification endpoint that is provided by the API consumer,\ne.g. during creation of the PM job or threshold resource. See clause 6.4.9.3.2.\n","responses":{"204":{"$ref":""},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/URI_is_provided_by_the_client_when_creating_the_subscription-ThresholdCrossedNotification":{"parameters":[{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"post":{"description":"The POST method delivers a notification regarding a performance management event from API producer to an\nAPI consumer. The API consumer shall have previously created an \"Individual PM job\" resource\nor \"Individual threshold\" resource. See clause 6.4.9.3.1.\n","parameters":[{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/ThresholdCrossedNotification"},"responses":{"204":{"$ref":"#/components/responses/ThresholdCrossedNotification.Post.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"get":{"description":"The GET method allows the API producer to test the notification endpoint that is provided by the API consumer,\ne.g. during creation of the PM job or threshold resource. See clause 6.4.9.3.2.\n","responses":{"204":{"$ref":"#/components/responses/ThresholdCrossedNotification.Get.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"requestBodies":{"PerformanceInformationAvailableNotification":{"description":"Notification about performance information availability.\n","content":{"application/json":{"schema":{"description":"This notification informs the receiver that performance information is available. The notification shall be triggered by the VNFM when new performance information collected by a PM job is available. The periodicity of triggering this notification is influenced by the \"reportingPeriod\" attribute in the \"PmJobCriteria\" data structure.\n","type":"object","required":["id","notificationType","timeStamp","pmJobId","objectType","objectInstanceId","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"PerformanceInformationAvailableNotification\" for this notification type.\n","type":"string","enum":["PerformanceInformationAvailableNotification"]},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"pmJobId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance for which the measurements have been taken. Shall be present if the related PM job has been set up to measure only a subset of all sub-object instances of the measured object instance and a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type. Shall be absent otherwise.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"_links":{"description":"Links to resources related to this notification.\n","type":"object","required":["pmJob","performanceReport"],"properties":{"objectInstance":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"pmJob":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"performanceReport":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true},"ThresholdCrossedNotification":{"description":"Notification about performance information availability.\n","content":{"application/json":{"schema":{"description":"This type represents a notification that is sent when a threshold has been crossed.\nNOTE:\tThe timing of sending this notification is determined by the capability of the \n producing entity to evaluate the threshold crossing condition.\n \nThe notification shall be triggered by the VNFM when a threshold has been crossed.\nNOTE:\tThe sub-object allows to structure the measured object, but is not to be confused \n with sub-counters which allow to structure the measurement.\n","type":"object","required":["id","notificationType","timeStamp","thresholdId","crossingDirection","objectType","objectInstanceId","performanceMetric","performanceValue","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"notificationType":{"description":"Discriminator for the different notification types. Shall be set to \"ThresholdCrossedNotification\" for this notification type.\n","type":"string","enum":["ThresholdCrossedNotification"]},"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"thresholdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"crossingDirection":{"type":"string","enum":["UP","DOWN"]},"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"performanceMetric":{"description":"Performance metric associated with the threshold. This attribute shall contain the related \"Measurement Name\" value as defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"performanceValue":{"description":"Value of the metric that resulted in threshold crossing. The type of this attribute shall correspond to the related \"Measurement Unit\" as defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"object"},"context":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this notification.\n","type":"object","required":["threshold"],"properties":{"objectInstance":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"threshold":{"description":"This type represents a link to a resource in a notification, using an absolute or relative URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true}},"responses":{"PerformanceInformationAvailableNotification.Post.204":{"description":"204 NO CONTENT\n\nShall be returned when the notification has been delivered successfully.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","style":"simple","explode":false,"schema":{"type":"string"}}}},"PerformanceInformationAvailableNotification.Get.204":{"description":"204 NO CONTENT\n\nShall be returned to indicate that the notification endpoint has been tested successfully.\nThe response body shall be empty.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","style":"simple","explode":false,"schema":{"type":"string"}}}},"ThresholdCrossedNotification.Post.204":{"description":"204 NO CONTENT\n\nShall be returned when the notification has been delivered successfully.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","style":"simple","explode":false,"schema":{"type":"string"}}}},"ThresholdCrossedNotification.Get.204":{"description":"204 NO CONTENT\n\nShall be returned to indicate that the notification endpoint has been tested successfully.\nThe response body shall be empty.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"Version of the API used in the response.\n","style":"simple","explode":false,"schema":{"type":"string"}}}}}}} diff --git a/v5.3.1/SOL003-VNFPerformanceManagementNotification-API.yaml b/v5.3.1/SOL003-VNFPerformanceManagementNotification-API.yaml new file mode 100644 index 00000000..76d432fb --- /dev/null +++ b/v5.3.1/SOL003-VNFPerformanceManagementNotification-API.yaml @@ -0,0 +1,3188 @@ +openapi: 3.0.2 +info: + title: SOL003 - VNF Performance Management Notification interface + description: | + SOL003 - VNF Performance Management Notification interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '2.13.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 003 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf +servers: + - url: 'http://127.0.0.1/callback/v2' + - url: 'https://127.0.0.1/callback/v2' +paths: + /URI_is_provided_by_the_client_when_creating_the_subscription-PerformanceInformationAvailableNotification: + parameters: + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + post: + description: > + The POST method delivers a notification regarding a performance + management event from API producer to an + + API consumer. The API consumer shall have previously created an + "Individual PM job" resource + + or "Individual threshold" resource. See clause 6.4.9.3.1. + parameters: + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/PerformanceInformationAvailableNotification' + responses: + '204': + $ref: >- + #/components/responses/PerformanceInformationAvailableNotification.Post.204 + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + get: + description: > + The GET method allows the API producer to test the notification endpoint + that is provided by the API consumer, + + e.g. during creation of the PM job or threshold resource. See clause + 6.4.9.3.2. + responses: + '204': + $ref: >- + #/components/responses/PerformanceInformationAvailableNotification.Get.204 + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /URI_is_provided_by_the_client_when_creating_the_subscription-ThresholdCrossedNotification: + parameters: + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + post: + description: > + The POST method delivers a notification regarding a performance + management event from API producer to an + + API consumer. The API consumer shall have previously created an + "Individual PM job" resource + + or "Individual threshold" resource. See clause 6.4.9.3.1. + parameters: + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/ThresholdCrossedNotification' + responses: + '204': + $ref: '#/components/responses/ThresholdCrossedNotification.Post.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + get: + description: > + The GET method allows the API producer to test the notification endpoint + that is provided by the API consumer, + + e.g. during creation of the PM job or threshold resource. See clause + 6.4.9.3.2. + responses: + '204': + $ref: '#/components/responses/ThresholdCrossedNotification.Get.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + requestBodies: + PerformanceInformationAvailableNotification: + description: | + Notification about performance information availability. + content: + application/json: + schema: + description: > + This notification informs the receiver that performance + information is available. The notification shall be triggered by + the VNFM when new performance information collected by a PM job is + available. The periodicity of triggering this notification is + influenced by the "reportingPeriod" attribute in the + "PmJobCriteria" data structure. + type: object + required: + - id + - notificationType + - timeStamp + - pmJobId + - objectType + - objectInstanceId + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall be + set to "PerformanceInformationAvailableNotification" for this + notification type. + type: string + enum: + - PerformanceInformationAvailableNotification + timeStamp: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + pmJobId: + description: | + An identifier with the intention of being globally unique. + type: string + objectType: + description: > + Type of the measured object. The applicable measured object + type for a measurement is defined in clause 7.2 of ETSI GS + NFV-IFA 027. + type: string + objectInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + subObjectInstanceIds: + description: > + Identifiers of the sub-object instances of the measured object + instance for which the measurements have been taken. Shall be + present if the related PM job has been set up to measure only + a subset of all sub-object instances of the measured object + instance and a sub-object is defined in clause 6.2 of ETSI GS + NFV-IFA 027 for the related measured object type. Shall be + absent otherwise. + type: array + items: + description: > + An identifier that is unique for the respective type within + a VNF instance, but may not be globally unique. + type: string + _links: + description: | + Links to resources related to this notification. + type: object + required: + - pmJob + - performanceReport + properties: + objectInstance: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + pmJob: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + performanceReport: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + ThresholdCrossedNotification: + description: | + Notification about performance information availability. + content: + application/json: + schema: + description: "This type represents a notification that is sent when a threshold has been crossed.\nNOTE:\tThe timing of sending this notification is determined by the capability of the \n producing entity to evaluate the threshold crossing condition.\n \nThe notification shall be triggered by the VNFM when a threshold has been crossed.\nNOTE:\tThe sub-object allows to structure the measured object, but is not to be confused \n with sub-counters which allow to structure the measurement.\n" + type: object + required: + - id + - notificationType + - timeStamp + - thresholdId + - crossingDirection + - objectType + - objectInstanceId + - performanceMetric + - performanceValue + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + notificationType: + description: > + Discriminator for the different notification types. Shall be + set to "ThresholdCrossedNotification" for this notification + type. + type: string + enum: + - ThresholdCrossedNotification + timeStamp: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + thresholdId: + description: | + An identifier with the intention of being globally unique. + type: string + crossingDirection: + type: string + enum: + - UP + - DOWN + objectType: + description: > + Type of the measured object. The applicable measured object + type for a measurement is defined in clause 7.2 of ETSI GS + NFV-IFA 027. + type: string + objectInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + subObjectInstanceId: + description: > + An identifier that is unique for the respective type within a + VNF instance, but may not be globally unique. + type: string + performanceMetric: + description: > + Performance metric associated with the threshold. This + attribute shall contain the related "Measurement Name" value + as defined in clause 7.2 of ETSI GS NFV-IFA 027. + type: string + performanceValue: + description: > + Value of the metric that resulted in threshold crossing. The + type of this attribute shall correspond to the related + "Measurement Unit" as defined in clause 7.2 of ETSI GS NFV-IFA + 027. + type: object + context: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + _links: + description: | + Links to resources related to this notification. + type: object + required: + - threshold + properties: + objectInstance: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + threshold: + description: > + This type represents a link to a resource in a + notification, using an absolute or relative URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + responses: + PerformanceInformationAvailableNotification.Post.204: + description: | + 204 NO CONTENT + + Shall be returned when the notification has been delivered successfully. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: | + Version of the API used in the response. + style: simple + explode: false + schema: + type: string + PerformanceInformationAvailableNotification.Get.204: + description: > + 204 NO CONTENT + + + Shall be returned to indicate that the notification endpoint has been + tested successfully. + + The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: | + Version of the API used in the response. + style: simple + explode: false + schema: + type: string + ThresholdCrossedNotification.Post.204: + description: | + 204 NO CONTENT + + Shall be returned when the notification has been delivered successfully. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: | + Version of the API used in the response. + style: simple + explode: false + schema: + type: string + ThresholdCrossedNotification.Get.204: + description: > + 204 NO CONTENT + + + Shall be returned to indicate that the notification endpoint has been + tested successfully. + + The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: | + Version of the API used in the response. + style: simple + explode: false + schema: + type: string + diff --git a/v5.3.1/SOL003-VNFSnapshotPackageManagement-API.json b/v5.3.1/SOL003-VNFSnapshotPackageManagement-API.json new file mode 100644 index 00000000..63b8248c --- /dev/null +++ b/v5.3.1/SOL003-VNFSnapshotPackageManagement-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL003 - VNF Snapshot Package Management interface","description":"SOL003 - VNF Snapshot Package Management interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"1.12.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 003 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/vnfsnapshotpkgm/v1"},{"url":"https://127.0.0.1/vnfsnapshotpkgm/v1"}],"paths":{"/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_snapshot_packages":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method queries the information of the VNF packages matching the filter. See clause 12.4.2.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}},{"$ref":"#/components/parameters/filter_vnf_packages"},{"$ref":"#/components/parameters/exclude_default_vnf_packages"},{"name":"all_fields","description":"Include all complex attributes in the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The NFVO shall support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"fields","description":"Complex attributes to be included into the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The NFVO should support this parameter\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"exclude_fields","description":"Complex attributes to be excluded from the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The NFVO should support this parameter\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the NFVO if the NFVO supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/VNFSnapshotPackages.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_snapshot_packages/{vnfSnapshotPkgId}":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"$ref":"#/components/parameters/VnfSnapshotPkgId"}],"get":{"description":"The GET method reads the information of an individual VNF snapshot package. See clause 12.4.3.3.2\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualVNFSnapshotPackages.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_snapshot_packages/{vnfSnapshotPkgId}/package_content":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"$ref":"#/components/parameters/VnfSnapshotPkgId"}],"get":{"description":"The GET method fetches the content of a VNF snapshot package. See clause 12.4.4.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/PackageContent.Get.200"},"206":{"$ref":"#/components/responses/PackageContent.Get.206"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/PackageContent.Get.409"},"416":{"$ref":"#/components/responses/PackageContent.Get.416"},"422":{"description":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/vnf_snapshot_packages/{vnfSnapshotPkgId}/artifacts/{artifactPath}":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"$ref":"#/components/parameters/VnfSnapshotPkgId"},{"$ref":"#/components/parameters/ArtifactPath"}],"get":{"description":"The GET method fetches the content of an artifact within the VNF snapshot package. See clause 12.4.5.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualArtifact.Get.200"},"206":{"$ref":"#/components/responses/IndividualArtifact.Get.206"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/IndividualArtifact.Get.409"},"416":{"$ref":"#/components/responses/IndividualArtifact.Get.416"},"422":{"description":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"parameters":{"filter_vnf_packages":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013 [8]. The NFVO shall support receiving this parameter as part of the URI query string. The VNFM may supply this parameter. All attribute names that appear in the VnfSnapshotPkgInfo and in data types referenced from it shall be supported by the NFVO in the filter expression.\n","in":"query","required":false,"schema":{"type":"string"}},"exclude_default_vnf_packages":{"name":"exclude_default","in":"query","description":"Indicates to exclude the following complex attributes from the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The NFVO shall support this parameter. The following attributes shall be excluded from the VnfSnapshotPkgInfo structure in the response body if this parameter is provided, or none of the parameters \"all_fields,\" \"fields\", \"exclude_fields\", \"exclude_default\" are provided: - vnfcSnapshotImages\n - additionalArtifacts\n - userDefinedData\n - checksum\n","required":false,"schema":{"type":"string"}},"VnfSnapshotPkgId":{"name":"vnfSnapshotPkgId","in":"path","description":"Identifier of the VNF snapshot package. The identifier is allocated by the NFVO.\nThis identifier can be retrieved from the \"id\" attribute of the applicable \"VnfSnapshotPkgInfo\" in the body of\nthe response to requesting the creation of a new \"Individual VNF snapshot package\" resource or in a response to\na GET request querying the \"Individual VNF snapshot package\" or the \"VNF snapshot packages\" resource.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"ArtifactPath":{"name":"artifactPath","in":"path","description":"For an artifact contained as a file in the VNF snapshot package, this variable shall contain a sequence\nof one or path segments representing the path of the artifact within the VNF snapshot package, relative\nto the root of the package.\n\nEXAMPLE: foo/bar/m%40ster.sh\n\nFor an external artifact represented as a URI in the VNF snapshot package manifest, this variable shall\ncontain a sequence of one or more path segments as synthesized by the NFVO (see clause 12.5.3.3) representing\nthis artifact.\n\nThis identifier can be retrieved from the \"artifactPath\" attribute of the applicable \"additionalArtifacts\"\nentry in the body of the response to a GET request querying the \"Individual VNF snapshot package\" or the\n\"VNF snapshot packages\" resource.\n\nSince multiple path segments are allowed to be contained in this variable, the \"/\" character that separates\nthese segments is not percent-encoded. Each individual segment is percent-encoded if necessary as defined\nin clause 4.1 of ETSI GS NFV-SOL 013.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}}},"responses":{"VNFSnapshotPackages.Get.200":{"description":"200 OK\n\nShall be returned when information about zero or more VNF snapshot packages has been queried successfully.\n\nThe response body shall contain in an array the VNF snapshot package info representations that match the\nattribute filter, i.e. zero or more VNF snapshot package info representations as defined in clause 12.5.2.2.\n\nIf the \"filter\" URI parameter or one of the \"all_fields\", \"fields\", \"exclude_fields\" or \"exclude_default\"\nURI parameters was supplied in the request and is supported, the data in the response body shall have been\ntransformed according to the rules specified in clauses 5.2.2 and 5.3.2 of ETSI GS NFV-SOL 013, respectively.\n\nIf the NFVO supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this\nresource, inclusion of the Link HTTP header in this response shall follow the provisions in clause 5.4.2.3\nof ETSI GS NFV-SOL 013.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents the information of a VNF snapshot package.\nNOTE:\tThe attribute shall not be present before the VNF snapshot package content has been uploaded or built.\n Otherwise, this attribute shall be present unless it has been requested to be excluded per attribute selector.\n","type":"object","required":["id","name","isFullSnapshot","state","isCancelPending","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfSnapshotPkgUniqueId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"checksum":{"description":"Cheksum description\n","type":"string"},"createdAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfSnapshotId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcSnapshotInfoIds":{"description":"Identifiers of information held by the VNFM about specific VNFC snapshots part of the VNF snapshot and contained in the VNF snapshot package. This identifier is allocated by the VNFM during the VNF snapshot creation.\nSee note.\n","type":"object","items":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"}},"isFullSnapshot":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"vnfdInfo":{"description":"This type represents the VNFD which is contained in a VNF snapshot package.\n","type":"object","required":["avnfdId","vnfdPath","checksum","isEncrypted"],"properties":{"avnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfdPath":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"checksum":{"description":"Cheksum description\n","type":"string"},"isEncrypted":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"}}},"vnfsr":{"description":"This type represents the VNF snapshot record which is contained in a VNF snapshot package.\n","type":"object","required":["recordPath","checksum","isEncrypted"],"properties":{"recordPath":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"checksum":{"description":"Cheksum description\n","type":"string"},"isEncrypted":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"}}},"vnfcSnapshotImages":{"description":"Information about VNF snapshot artifacts that are VNFC snapshot images. Every local and external snapshot image shall be included. No other artifacts shall be included.\nSee note.\n","type":"object","items":{"description":"This type represents an artifact contained in a VNF snapshot package which represents a snapshot image.\nNOTE 1:\tThe list of permitted values was taken from \"Container formats\" in OpenStack® documentation: \"Disk and container formats for images\"\n (Available at https://docs.openstack.org/glance/pike/user/formats.html).\nNOTE 2:\tThe list of permitted values was adapted from \"Disk formats\" in OpenStack® documentation: \"Disk and container formats for images\"\n (Available at https://docs.openstack.org/glance/pike/user/formats.html).\n","type":"object","required":["id","name","checksum","isEncrypted","vnfcInstanceId","containerFormat","diskFormat","createdAt","minDisk","minRam","size"],"properties":{"id":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"name":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"checksum":{"description":"Cheksum description\n","type":"string"},"isEncrypted":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"vnfcInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"containerFormat":{"description":"Container format indicates whether the snapshot image is in a file format that also contains metadata about the actual snapshot.\nPermitted values: - AKI: a kernel image format - AMI: a machine image format - ARI: a ramdisk image format - BARE: the image does not have a container or metadata envelope - DOCKER: docker container format - OVA: OVF package in a tarfile - OVF: OVF container format\nSee note 1.\n","type":"string","enum":["AKI","AMI","ARI","BARE","DOCKER","OVA","OVF"]},"diskFormat":{"description":"Disk format of a snapshot image is the format of the underlying disk image.\nPermitted values: - AKI: a kernel image format - AMI: a machine image format - ARI: a ramdisk image format - ISO: an archive format for the data contents of an optical disc, such as CD-ROM - QCOW2: a common disk image format, which can expand dynamically and supports copy on write - RAW: an unstructured disk image format - VDI: a common disk image format - VHD: a common disk image format - VHDX: enhanced version of VHD format - VMDK: a common disk image format\nSee note 2.\n","type":"string","enum":["AKI","AMI","ARI","ISO","QCOW2","RAW","VDI","VHD","VHDX","VMDK"]},"createdAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"minDisk":{"description":"Unsigned integer number\n","type":"integer","minimum":0},"minRam":{"description":"Unsigned integer number\n","type":"integer","minimum":0},"size":{"description":"Unsigned integer number\n","type":"integer","minimum":0},"userMetadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"imagePath":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"imageUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}},"additionalArtifacts":{"description":"Information about VNF snapshot artifacts that are not VNFC snapshot images.\nSee note.\n","type":"object","items":{"description":"This type represents an artifact other than a software image which is contained in a VNF snapshot package.\n","type":"object","required":["checksum","isEncrypted"],"properties":{"artifactPath":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"artifactUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"checksum":{"description":"Cheksum description\n","type":"string"},"isEncrypted":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"state":{"description":"State of the VNF snapshot package. Permitted values: - CREATED: the VNF snapshot package information has been created. - BUILDING: the VNF snapshot package is being built. - UPLOADING: the VNF snapshot package is being uploaded. - EXTRACTING: the VNF snapshot package's content is being extracted. - AVAILABLE: the VNF snapshot package is available (i.e., build or upload is completed). - PROCESSING: the VNF snapshot is being processed. - ERROR: failure during the VNF snapshot package building, uploading or processing. - ERROR_EXTRACTING: failure during the VNF snapshot package extraction task.\n","type":"string","enum":["CREATED","BUILDING","UPLOADING","EXTRACTING","AVAILABLE","PROCESSING","ERROR","ERROR_EXTRACTING"]},"isCancelPending":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"failureDetails":{"description":"Failure details associated to current error state of the VNF snapshot package state. If \"state\" is \"ERROR\" or \"ERROR_EXTRACTING\", this attribute shall be present unless it has been requested to be excluded via an attribute selector.\n","type":"object","required":["errorType","details"],"properties":{"errorType":{"description":"Type of error, when the failure happened (building, upload, processing, extracting).\nPermitted values: - BUILD_ERROR - UPLOAD_ERROR - PROCESS_ERROR - CANCELLED - EXTRACTION_ERROR\n","type":"string","enum":["BUILD_ERROR","UPLOAD_ERROR","PROCESS_ERROR","CANCELLED","EXTRACTION_ERROR"]},"details":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self","packageContent"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"packageContent":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"IndividualVNFSnapshotPackages.Get.200":{"description":"200 OK\n\nShall be returned when information of the VNF snapshot package has been read successfully.\n\nThe response body shall contain the VNF snapshot package info representation defined in clause 12.5.2.2.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents the information of a VNF snapshot package.\nNOTE:\tThe attribute shall not be present before the VNF snapshot package content has been uploaded or built.\n Otherwise, this attribute shall be present unless it has been requested to be excluded per attribute selector.\n","type":"object","required":["id","name","isFullSnapshot","state","isCancelPending","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfSnapshotPkgUniqueId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"name":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"checksum":{"description":"Cheksum description\n","type":"string"},"createdAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"vnfSnapshotId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfcSnapshotInfoIds":{"description":"Identifiers of information held by the VNFM about specific VNFC snapshots part of the VNF snapshot and contained in the VNF snapshot package. This identifier is allocated by the VNFM during the VNF snapshot creation.\nSee note.\n","type":"object","items":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"}},"isFullSnapshot":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"vnfdInfo":{"description":"This type represents the VNFD which is contained in a VNF snapshot package.\n","type":"object","required":["avnfdId","vnfdPath","checksum","isEncrypted"],"properties":{"avnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfdPath":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"checksum":{"description":"Cheksum description\n","type":"string"},"isEncrypted":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"}}},"vnfsr":{"description":"This type represents the VNF snapshot record which is contained in a VNF snapshot package.\n","type":"object","required":["recordPath","checksum","isEncrypted"],"properties":{"recordPath":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"checksum":{"description":"Cheksum description\n","type":"string"},"isEncrypted":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"}}},"vnfcSnapshotImages":{"description":"Information about VNF snapshot artifacts that are VNFC snapshot images. Every local and external snapshot image shall be included. No other artifacts shall be included.\nSee note.\n","type":"object","items":{"description":"This type represents an artifact contained in a VNF snapshot package which represents a snapshot image.\nNOTE 1:\tThe list of permitted values was taken from \"Container formats\" in OpenStack® documentation: \"Disk and container formats for images\"\n (Available at https://docs.openstack.org/glance/pike/user/formats.html).\nNOTE 2:\tThe list of permitted values was adapted from \"Disk formats\" in OpenStack® documentation: \"Disk and container formats for images\"\n (Available at https://docs.openstack.org/glance/pike/user/formats.html).\n","type":"object","required":["id","name","checksum","isEncrypted","vnfcInstanceId","containerFormat","diskFormat","createdAt","minDisk","minRam","size"],"properties":{"id":{"description":"An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length.\n","type":"string"},"name":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"checksum":{"description":"Cheksum description\n","type":"string"},"isEncrypted":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"vnfcInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"containerFormat":{"description":"Container format indicates whether the snapshot image is in a file format that also contains metadata about the actual snapshot.\nPermitted values: - AKI: a kernel image format - AMI: a machine image format - ARI: a ramdisk image format - BARE: the image does not have a container or metadata envelope - DOCKER: docker container format - OVA: OVF package in a tarfile - OVF: OVF container format\nSee note 1.\n","type":"string","enum":["AKI","AMI","ARI","BARE","DOCKER","OVA","OVF"]},"diskFormat":{"description":"Disk format of a snapshot image is the format of the underlying disk image.\nPermitted values: - AKI: a kernel image format - AMI: a machine image format - ARI: a ramdisk image format - ISO: an archive format for the data contents of an optical disc, such as CD-ROM - QCOW2: a common disk image format, which can expand dynamically and supports copy on write - RAW: an unstructured disk image format - VDI: a common disk image format - VHD: a common disk image format - VHDX: enhanced version of VHD format - VMDK: a common disk image format\nSee note 2.\n","type":"string","enum":["AKI","AMI","ARI","ISO","QCOW2","RAW","VDI","VHD","VHDX","VMDK"]},"createdAt":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"minDisk":{"description":"Unsigned integer number\n","type":"integer","minimum":0},"minRam":{"description":"Unsigned integer number\n","type":"integer","minimum":0},"size":{"description":"Unsigned integer number\n","type":"integer","minimum":0},"userMetadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"imagePath":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"imageUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}},"additionalArtifacts":{"description":"Information about VNF snapshot artifacts that are not VNFC snapshot images.\nSee note.\n","type":"object","items":{"description":"This type represents an artifact other than a software image which is contained in a VNF snapshot package.\n","type":"object","required":["checksum","isEncrypted"],"properties":{"artifactPath":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"artifactUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"checksum":{"description":"Cheksum description\n","type":"string"},"isEncrypted":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"metadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}},"state":{"description":"State of the VNF snapshot package. Permitted values: - CREATED: the VNF snapshot package information has been created. - BUILDING: the VNF snapshot package is being built. - UPLOADING: the VNF snapshot package is being uploaded. - EXTRACTING: the VNF snapshot package's content is being extracted. - AVAILABLE: the VNF snapshot package is available (i.e., build or upload is completed). - PROCESSING: the VNF snapshot is being processed. - ERROR: failure during the VNF snapshot package building, uploading or processing. - ERROR_EXTRACTING: failure during the VNF snapshot package extraction task.\n","type":"string","enum":["CREATED","BUILDING","UPLOADING","EXTRACTING","AVAILABLE","PROCESSING","ERROR","ERROR_EXTRACTING"]},"isCancelPending":{"description":"The Boolean is a data type having two values (true and false).\n","type":"boolean"},"failureDetails":{"description":"Failure details associated to current error state of the VNF snapshot package state. If \"state\" is \"ERROR\" or \"ERROR_EXTRACTING\", this attribute shall be present unless it has been requested to be excluded via an attribute selector.\n","type":"object","required":["errorType","details"],"properties":{"errorType":{"description":"Type of error, when the failure happened (building, upload, processing, extracting).\nPermitted values: - BUILD_ERROR - UPLOAD_ERROR - PROCESS_ERROR - CANCELLED - EXTRACTION_ERROR\n","type":"string","enum":["BUILD_ERROR","UPLOAD_ERROR","PROCESS_ERROR","CANCELLED","EXTRACTION_ERROR"]},"details":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self","packageContent"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"packageContent":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"PackageContent.Get.200":{"description":"200 OK\n\nShall be returned when the whole content of the VNF snapshot package file has been read successfully.\n\nThe response body shall include a copy of the VNF snapshot package file.\n\nThe \"Content-Type\" HTTP header shall be set according to the type of the file, i.e. to \"application/zip\"\nfor a VNF snapshot package. The VNF snapshot package format is defined in ETSI GS NFV-SOL 010.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/*":{"schema":{"type":"string","format":"binary"}}}},"PackageContent.Get.206":{"description":"206 PARTIAL CONTENT\n\nIf the NFVO supports range requests, this response shall be returned when a single consecutive byte range\nfrom the content of the VNF snapshot package file has been read successfully according to the request.\n\nThe response body shall contain the requested part of the VNF snapshot package file. The \"Content-Range\"\nHTTP header shall be provided according to IETF RFC 49110 [19]. The \"Content-Type\" HTTP header shall be set as\ndefined above for the \"200 OK\" response.\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Range":{"description":"The Content-Range response HTTP header indicates where in a full body message a partial message belongs.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/*":{"schema":{"type":"string","format":"binary"}}}},"PackageContent.Get.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact the \"state\" of the\nVNF snapshot package has a value different from\n\"AVAILABLE\".\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"PackageContent.Get.416":{"description":"416 Range Not Satisfiable\n\nShall be returned upon the following error: The byte\nrange passed in the \"Range\" header did not match\nany available byte range in the VNF snapshot\npackage file (e.g. \"access after end of file\").\nThe response body may contain a ProblemDetails\nstructure\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualArtifact.Get.200":{"description":"200 OK\n\nShall be returned when the whole content of the artifact file has been read successfully.\n\nThe response body shall include a copy of the artifact file from the VNF snapshot package.\nThe VNF snapshot package format is defined in ETSI GS NFV-SOL 010.\n\nThe \"Content-Type\" HTTP header shall be set according to the content type of the artifact file.\nIf the content type cannot be determined, the header shall be set to the value \"application/octet-stream\".\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/*":{"schema":{"type":"string","format":"binary"}}}},"IndividualArtifact.Get.206":{"description":"206 PARTIAL CONTENT\n\nIf the NFVO supports range requests, this response shall be returned when a single consecutive byte range\nfrom the content of the artifact file has been read successfully according to the request.\n\nThe response body shall contain the requested part of the artifact file from the VNF snapshot package.\nThe VNF snapshot package is defined in ETSI GS NFV-SOL 010.\n\nThe \"Content-Type\" HTTP header shall be set according to the content type of the artifact file. If the\ncontent type cannot be determined, the header shall be set to the value \"application/octet-stream\".\n\nThe \"Content-Range\" HTTP header shall be provided according to IETF RFC 9110[20].\n","headers":{"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Range":{"description":"The Content-Range response HTTP header indicates where in a full body message a partial message belongs.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/*":{"schema":{"type":"string","format":"binary"}}}},"IndividualArtifact.Get.409":{"description":"409 CONFLICT\n\nShall be returned upon the following error: The\noperation cannot be executed currently, due to a\nconflict with the state of the resource.\nTypically, this is due to the fact the \"state\" of the\nVNF snapshot package has a value different from\n\"AVAILABLE\".\nThe response body shall contain a ProblemDetails\nstructure, in which the \"detail\" attribute shall convey\nmore information about the error.\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"IndividualArtifact.Get.416":{"description":"416 Range Not Satisfiable\n\nShall be returned upon the following error: The byte\nrange passed in the \"Range\" header did not match\nany available byte range in the artifact file\n(e.g. \"access after end of file\").\nThe response body may contain a ProblemDetails\nstructure\n","headers":{"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}}}}} diff --git a/v5.3.1/SOL003-VNFSnapshotPackageManagement-API.yaml b/v5.3.1/SOL003-VNFSnapshotPackageManagement-API.yaml new file mode 100644 index 00000000..3eefbd5b --- /dev/null +++ b/v5.3.1/SOL003-VNFSnapshotPackageManagement-API.yaml @@ -0,0 +1,7810 @@ +openapi: 3.0.2 +info: + title: SOL003 - VNF Snapshot Package Management interface + description: | + SOL003 - VNF Snapshot Package Management interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '1.12.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 003 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf +servers: + - url: 'http://127.0.0.1/vnfsnapshotpkgm/v1' + - url: 'https://127.0.0.1/vnfsnapshotpkgm/v1' +paths: + /api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /vnf_snapshot_packages: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: > + The GET method queries the information of the VNF packages matching the + filter. See clause 12.4.2.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + - $ref: '#/components/parameters/filter_vnf_packages' + - $ref: '#/components/parameters/exclude_default_vnf_packages' + - name: all_fields + description: > + Include all complex attributes in the response. See clause 5.3 of + ETSI GS NFV-SOL 013 [8] for details. The NFVO shall support this + parameter. + in: query + required: false + schema: + type: string + - name: fields + description: > + Complex attributes to be included into the response. See clause 5.3 + of ETSI GS NFV-SOL 013 [8] for details. The NFVO should support this + parameter + in: query + required: false + schema: + type: string + - name: exclude_fields + description: > + Complex attributes to be excluded from the response. See clause 5.3 + of ETSI GS NFV-SOL 013 [8] for details. The NFVO should support this + parameter + in: query + required: false + schema: + type: string + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the NFVO if the NFVO supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this + resource. + in: query + required: false + schema: + type: string + responses: + '200': + $ref: '#/components/responses/VNFSnapshotPackages.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_snapshot_packages/{vnfSnapshotPkgId}': + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - $ref: '#/components/parameters/VnfSnapshotPkgId' + get: + description: > + The GET method reads the information of an individual VNF snapshot + package. See clause 12.4.3.3.2 + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualVNFSnapshotPackages.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_snapshot_packages/{vnfSnapshotPkgId}/package_content': + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - $ref: '#/components/parameters/VnfSnapshotPkgId' + get: + description: > + The GET method fetches the content of a VNF snapshot package. See clause + 12.4.4.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/PackageContent.Get.200' + '206': + $ref: '#/components/responses/PackageContent.Get.206' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/PackageContent.Get.409' + '416': + $ref: '#/components/responses/PackageContent.Get.416' + '422': + description: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/vnf_snapshot_packages/{vnfSnapshotPkgId}/artifacts/{artifactPath}': + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - $ref: '#/components/parameters/VnfSnapshotPkgId' + - $ref: '#/components/parameters/ArtifactPath' + get: + description: > + The GET method fetches the content of an artifact within the VNF + snapshot package. See clause 12.4.5.3.2. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + responses: + '200': + $ref: '#/components/responses/IndividualArtifact.Get.200' + '206': + $ref: '#/components/responses/IndividualArtifact.Get.206' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/IndividualArtifact.Get.409' + '416': + $ref: '#/components/responses/IndividualArtifact.Get.416' + '422': + description: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + parameters: + filter_vnf_packages: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013 [8]. The NFVO shall support receiving this parameter as part + of the URI query string. The VNFM may supply this parameter. All + attribute names that appear in the VnfSnapshotPkgInfo and in data types + referenced from it shall be supported by the NFVO in the filter + expression. + in: query + required: false + schema: + type: string + exclude_default_vnf_packages: + name: exclude_default + in: query + description: > + Indicates to exclude the following complex attributes from the response. + See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The NFVO shall + support this parameter. The following attributes shall be excluded from + the VnfSnapshotPkgInfo structure in the response body if this parameter + is provided, or none of the parameters "all_fields," "fields", + "exclude_fields", "exclude_default" are provided: + - vnfcSnapshotImages + - additionalArtifacts + - userDefinedData + - checksum + required: false + schema: + type: string + VnfSnapshotPkgId: + name: vnfSnapshotPkgId + in: path + description: > + Identifier of the VNF snapshot package. The identifier is allocated by + the NFVO. + + This identifier can be retrieved from the "id" attribute of the + applicable "VnfSnapshotPkgInfo" in the body of + + the response to requesting the creation of a new "Individual VNF + snapshot package" resource or in a response to + + a GET request querying the "Individual VNF snapshot package" or the "VNF + snapshot packages" resource. + required: true + style: simple + explode: false + schema: + type: string + ArtifactPath: + name: artifactPath + in: path + description: > + For an artifact contained as a file in the VNF snapshot package, this + variable shall contain a sequence + + of one or path segments representing the path of the artifact within the + VNF snapshot package, relative + + to the root of the package. + + + EXAMPLE: foo/bar/m%40ster.sh + + + For an external artifact represented as a URI in the VNF snapshot + package manifest, this variable shall + + contain a sequence of one or more path segments as synthesized by the + NFVO (see clause 12.5.3.3) representing + + this artifact. + + + This identifier can be retrieved from the "artifactPath" attribute of + the applicable "additionalArtifacts" + + entry in the body of the response to a GET request querying the + "Individual VNF snapshot package" or the + + "VNF snapshot packages" resource. + + + Since multiple path segments are allowed to be contained in this + variable, the "/" character that separates + + these segments is not percent-encoded. Each individual segment is + percent-encoded if necessary as defined + + in clause 4.1 of ETSI GS NFV-SOL 013. + required: true + style: simple + explode: false + schema: + type: string + responses: + VNFSnapshotPackages.Get.200: + description: > + 200 OK + + + Shall be returned when information about zero or more VNF snapshot + packages has been queried successfully. + + + The response body shall contain in an array the VNF snapshot package + info representations that match the + + attribute filter, i.e. zero or more VNF snapshot package info + representations as defined in clause 12.5.2.2. + + + If the "filter" URI parameter or one of the "all_fields", "fields", + "exclude_fields" or "exclude_default" + + URI parameters was supplied in the request and is supported, the data in + the response body shall have been + + transformed according to the rules specified in clauses 5.2.2 and 5.3.2 + of ETSI GS NFV-SOL 013, respectively. + + + If the NFVO supports alternative 2 (paging) according to clause 5.4.2.1 + of ETSI GS NFV-SOL 013 for this + + resource, inclusion of the Link HTTP header in this response shall + follow the provisions in clause 5.4.2.3 + + of ETSI GS NFV-SOL 013. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: "This type represents the information of a VNF snapshot package.\nNOTE:\tThe attribute shall not be present before the VNF snapshot package content has been uploaded or built.\n Otherwise, this attribute shall be present unless it has been requested to be excluded per attribute selector.\n" + type: object + required: + - id + - name + - isFullSnapshot + - state + - isCancelPending + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfSnapshotPkgUniqueId: + description: | + An identifier with the intention of being globally unique. + type: string + name: + description: | + A string defined in IETF RFC 8259. + type: string + checksum: + description: | + Cheksum description + type: string + createdAt: + description: > + Date-time stamp. Representation: String formatted according + to IETF RFC 3339. + type: string + format: date-time + vnfSnapshotId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfcSnapshotInfoIds: + description: > + Identifiers of information held by the VNFM about specific + VNFC snapshots part of the VNF snapshot and contained in + the VNF snapshot package. This identifier is allocated by + the VNFM during the VNF snapshot creation. + + See note. + type: object + items: + description: > + An identifier that is unique within a limited local scope + other than above listed identifiers, such as within a + complex data structure or within a request-response pair. + Representation: string of variable length. + type: string + isFullSnapshot: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + vnfdInfo: + description: > + This type represents the VNFD which is contained in a VNF + snapshot package. + type: object + required: + - avnfdId + - vnfdPath + - checksum + - isEncrypted + properties: + avnfdId: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfdPath: + description: | + A string defined in IETF RFC 8259. + type: string + checksum: + description: | + Cheksum description + type: string + isEncrypted: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + vnfsr: + description: > + This type represents the VNF snapshot record which is + contained in a VNF snapshot package. + type: object + required: + - recordPath + - checksum + - isEncrypted + properties: + recordPath: + description: | + A string defined in IETF RFC 8259. + type: string + checksum: + description: | + Cheksum description + type: string + isEncrypted: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + vnfcSnapshotImages: + description: > + Information about VNF snapshot artifacts that are VNFC + snapshot images. Every local and external snapshot image + shall be included. No other artifacts shall be included. + + See note. + type: object + items: + description: "This type represents an artifact contained in a VNF snapshot package which represents a snapshot image.\nNOTE 1:\tThe list of permitted values was taken from \"Container formats\" in OpenStack® documentation: \"Disk and container formats for images\"\n (Available at https://docs.openstack.org/glance/pike/user/formats.html).\nNOTE 2:\tThe list of permitted values was adapted from \"Disk formats\" in OpenStack® documentation: \"Disk and container formats for images\"\n (Available at https://docs.openstack.org/glance/pike/user/formats.html).\n" + type: object + required: + - id + - name + - checksum + - isEncrypted + - vnfcInstanceId + - containerFormat + - diskFormat + - createdAt + - minDisk + - minRam + - size + properties: + id: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + name: + description: | + A string defined in IETF RFC 8259. + type: string + checksum: + description: | + Cheksum description + type: string + isEncrypted: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + vnfcInstanceId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + containerFormat: + description: > + Container format indicates whether the snapshot image + is in a file format that also contains metadata about + the actual snapshot. + + Permitted values: - AKI: a kernel image format - AMI: + a machine image format - ARI: a ramdisk image format - + BARE: the image does not have a container or metadata + envelope - DOCKER: docker container format - OVA: OVF + package in a tarfile - OVF: OVF container format + + See note 1. + type: string + enum: + - AKI + - AMI + - ARI + - BARE + - DOCKER + - OVA + - OVF + diskFormat: + description: > + Disk format of a snapshot image is the format of the + underlying disk image. + + Permitted values: - AKI: a kernel image format - AMI: + a machine image format - ARI: a ramdisk image format - + ISO: an archive format for the data contents of an + optical disc, such as CD-ROM - QCOW2: a common disk + image format, which can expand dynamically and + supports copy on write - RAW: an unstructured disk + image format - VDI: a common disk image format - VHD: + a common disk image format - VHDX: enhanced version of + VHD format - VMDK: a common disk image format + + See note 2. + type: string + enum: + - AKI + - AMI + - ARI + - ISO + - QCOW2 + - RAW + - VDI + - VHD + - VHDX + - VMDK + createdAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + minDisk: + description: | + Unsigned integer number + type: integer + minimum: 0 + minRam: + description: | + Unsigned integer number + type: integer + minimum: 0 + size: + description: | + Unsigned integer number + type: integer + minimum: 0 + userMetadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + imagePath: + description: | + A string defined in IETF RFC 8259. + type: string + imageUri: + description: | + String formatted according to IETF RFC 3986. + type: string + additionalArtifacts: + description: > + Information about VNF snapshot artifacts that are not VNFC + snapshot images. + + See note. + type: object + items: + description: > + This type represents an artifact other than a software + image which is contained in a VNF snapshot package. + type: object + required: + - checksum + - isEncrypted + properties: + artifactPath: + description: | + A string defined in IETF RFC 8259. + type: string + artifactUri: + description: | + String formatted according to IETF RFC 3986. + type: string + checksum: + description: | + Cheksum description + type: string + isEncrypted: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + state: + description: > + State of the VNF snapshot package. Permitted values: - + CREATED: the VNF snapshot package information has been + created. - BUILDING: the VNF snapshot package is being + built. - UPLOADING: the VNF snapshot package is being + uploaded. - EXTRACTING: the VNF snapshot package's content + is being extracted. - AVAILABLE: the VNF snapshot package is + available (i.e., build or upload is completed). - + PROCESSING: the VNF snapshot is being processed. - ERROR: + failure during the VNF snapshot package building, uploading + or processing. - ERROR_EXTRACTING: failure during the VNF + snapshot package extraction task. + type: string + enum: + - CREATED + - BUILDING + - UPLOADING + - EXTRACTING + - AVAILABLE + - PROCESSING + - ERROR + - ERROR_EXTRACTING + isCancelPending: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + failureDetails: + description: > + Failure details associated to current error state of the VNF + snapshot package state. If "state" is "ERROR" or + "ERROR_EXTRACTING", this attribute shall be present unless + it has been requested to be excluded via an attribute + selector. + type: object + required: + - errorType + - details + properties: + errorType: + description: > + Type of error, when the failure happened (building, + upload, processing, extracting). + + Permitted values: - BUILD_ERROR - UPLOAD_ERROR - + PROCESS_ERROR - CANCELLED - EXTRACTION_ERROR + type: string + enum: + - BUILD_ERROR + - UPLOAD_ERROR + - PROCESS_ERROR + - CANCELLED + - EXTRACTION_ERROR + details: + description: > + The definition of the general "ProblemDetails" data + structure from IETF RFC 7807 is reproduced inthis + structure. Compared to the general framework defined in + IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + userDefinedData: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + - packageContent + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + packageContent: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualVNFSnapshotPackages.Get.200: + description: > + 200 OK + + + Shall be returned when information of the VNF snapshot package has been + read successfully. + + + The response body shall contain the VNF snapshot package info + representation defined in clause 12.5.2.2. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: "This type represents the information of a VNF snapshot package.\nNOTE:\tThe attribute shall not be present before the VNF snapshot package content has been uploaded or built.\n Otherwise, this attribute shall be present unless it has been requested to be excluded per attribute selector.\n" + type: object + required: + - id + - name + - isFullSnapshot + - state + - isCancelPending + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + vnfSnapshotPkgUniqueId: + description: | + An identifier with the intention of being globally unique. + type: string + name: + description: | + A string defined in IETF RFC 8259. + type: string + checksum: + description: | + Cheksum description + type: string + createdAt: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + vnfSnapshotId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfcSnapshotInfoIds: + description: > + Identifiers of information held by the VNFM about specific + VNFC snapshots part of the VNF snapshot and contained in the + VNF snapshot package. This identifier is allocated by the + VNFM during the VNF snapshot creation. + + See note. + type: object + items: + description: > + An identifier that is unique within a limited local scope + other than above listed identifiers, such as within a + complex data structure or within a request-response pair. + Representation: string of variable length. + type: string + isFullSnapshot: + description: | + The Boolean is a data type having two values (true and false). + type: boolean + vnfdInfo: + description: > + This type represents the VNFD which is contained in a VNF + snapshot package. + type: object + required: + - avnfdId + - vnfdPath + - checksum + - isEncrypted + properties: + avnfdId: + description: | + An identifier with the intention of being globally unique. + type: string + vnfdPath: + description: | + A string defined in IETF RFC 8259. + type: string + checksum: + description: | + Cheksum description + type: string + isEncrypted: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + vnfsr: + description: > + This type represents the VNF snapshot record which is + contained in a VNF snapshot package. + type: object + required: + - recordPath + - checksum + - isEncrypted + properties: + recordPath: + description: | + A string defined in IETF RFC 8259. + type: string + checksum: + description: | + Cheksum description + type: string + isEncrypted: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + vnfcSnapshotImages: + description: > + Information about VNF snapshot artifacts that are VNFC + snapshot images. Every local and external snapshot image + shall be included. No other artifacts shall be included. + + See note. + type: object + items: + description: "This type represents an artifact contained in a VNF snapshot package which represents a snapshot image.\nNOTE 1:\tThe list of permitted values was taken from \"Container formats\" in OpenStack® documentation: \"Disk and container formats for images\"\n (Available at https://docs.openstack.org/glance/pike/user/formats.html).\nNOTE 2:\tThe list of permitted values was adapted from \"Disk formats\" in OpenStack® documentation: \"Disk and container formats for images\"\n (Available at https://docs.openstack.org/glance/pike/user/formats.html).\n" + type: object + required: + - id + - name + - checksum + - isEncrypted + - vnfcInstanceId + - containerFormat + - diskFormat + - createdAt + - minDisk + - minRam + - size + properties: + id: + description: > + An identifier that is unique within a limited local + scope other than above listed identifiers, such as + within a complex data structure or within a + request-response pair. Representation: string of + variable length. + type: string + name: + description: | + A string defined in IETF RFC 8259. + type: string + checksum: + description: | + Cheksum description + type: string + isEncrypted: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + vnfcInstanceId: + description: > + An identifier that is unique for the respective type + within a VNF instance, but may not be globally unique. + type: string + containerFormat: + description: > + Container format indicates whether the snapshot image is + in a file format that also contains metadata about the + actual snapshot. + + Permitted values: - AKI: a kernel image format - AMI: a + machine image format - ARI: a ramdisk image format - + BARE: the image does not have a container or metadata + envelope - DOCKER: docker container format - OVA: OVF + package in a tarfile - OVF: OVF container format + + See note 1. + type: string + enum: + - AKI + - AMI + - ARI + - BARE + - DOCKER + - OVA + - OVF + diskFormat: + description: > + Disk format of a snapshot image is the format of the + underlying disk image. + + Permitted values: - AKI: a kernel image format - AMI: a + machine image format - ARI: a ramdisk image format - + ISO: an archive format for the data contents of an + optical disc, such as CD-ROM - QCOW2: a common disk + image format, which can expand dynamically and supports + copy on write - RAW: an unstructured disk image format - + VDI: a common disk image format - VHD: a common disk + image format - VHDX: enhanced version of VHD format - + VMDK: a common disk image format + + See note 2. + type: string + enum: + - AKI + - AMI + - ARI + - ISO + - QCOW2 + - RAW + - VDI + - VHD + - VHDX + - VMDK + createdAt: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + minDisk: + description: | + Unsigned integer number + type: integer + minimum: 0 + minRam: + description: | + Unsigned integer number + type: integer + minimum: 0 + size: + description: | + Unsigned integer number + type: integer + minimum: 0 + userMetadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + imagePath: + description: | + A string defined in IETF RFC 8259. + type: string + imageUri: + description: | + String formatted according to IETF RFC 3986. + type: string + additionalArtifacts: + description: > + Information about VNF snapshot artifacts that are not VNFC + snapshot images. + + See note. + type: object + items: + description: > + This type represents an artifact other than a software image + which is contained in a VNF snapshot package. + type: object + required: + - checksum + - isEncrypted + properties: + artifactPath: + description: | + A string defined in IETF RFC 8259. + type: string + artifactUri: + description: | + String formatted according to IETF RFC 3986. + type: string + checksum: + description: | + Cheksum description + type: string + isEncrypted: + description: > + The Boolean is a data type having two values (true and + false). + type: boolean + metadata: + description: > + This type represents a list of key-value pairs. The + order of the pairs in the list is not significant. In + JSON, a set of keyvalue pairs is represented as an + object. It shall comply with the provisions defined in + clause 4 of IETF RFC 8259. In the following example, a + list of key-value pairs with four keys ("aString", + "aNumber", "anArray" and "anObject") is provided to + illustrate that the values associated with different + keys can be of different type. + type: object + state: + description: > + State of the VNF snapshot package. Permitted values: - + CREATED: the VNF snapshot package information has been + created. - BUILDING: the VNF snapshot package is being built. + - UPLOADING: the VNF snapshot package is being uploaded. - + EXTRACTING: the VNF snapshot package's content is being + extracted. - AVAILABLE: the VNF snapshot package is available + (i.e., build or upload is completed). - PROCESSING: the VNF + snapshot is being processed. - ERROR: failure during the VNF + snapshot package building, uploading or processing. - + ERROR_EXTRACTING: failure during the VNF snapshot package + extraction task. + type: string + enum: + - CREATED + - BUILDING + - UPLOADING + - EXTRACTING + - AVAILABLE + - PROCESSING + - ERROR + - ERROR_EXTRACTING + isCancelPending: + description: | + The Boolean is a data type having two values (true and false). + type: boolean + failureDetails: + description: > + Failure details associated to current error state of the VNF + snapshot package state. If "state" is "ERROR" or + "ERROR_EXTRACTING", this attribute shall be present unless it + has been requested to be excluded via an attribute selector. + type: object + required: + - errorType + - details + properties: + errorType: + description: > + Type of error, when the failure happened (building, + upload, processing, extracting). + + Permitted values: - BUILD_ERROR - UPLOAD_ERROR - + PROCESS_ERROR - CANCELLED - EXTRACTION_ERROR + type: string + enum: + - BUILD_ERROR + - UPLOAD_ERROR + - PROCESS_ERROR + - CANCELLED + - EXTRACTION_ERROR + details: + description: > + The definition of the general "ProblemDetails" data + structure from IETF RFC 7807 is reproduced inthis + structure. Compared to the general framework defined in + IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + userDefinedData: + description: > + This type represents a list of key-value pairs. The order of + the pairs in the list is not significant. In JSON, a set of + keyvalue pairs is represented as an object. It shall comply + with the provisions defined in clause 4 of IETF RFC 8259. In + the following example, a list of key-value pairs with four + keys ("aString", "aNumber", "anArray" and "anObject") is + provided to illustrate that the values associated with + different keys can be of different type. + type: object + _links: + description: | + Links to resources related to this resource. + type: object + required: + - self + - packageContent + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + packageContent: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + PackageContent.Get.200: + description: > + 200 OK + + + Shall be returned when the whole content of the VNF snapshot package + file has been read successfully. + + + The response body shall include a copy of the VNF snapshot package + file. + + + The "Content-Type" HTTP header shall be set according to the type of the + file, i.e. to "application/zip" + + for a VNF snapshot package. The VNF snapshot package format is defined + in ETSI GS NFV-SOL 010. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/*: + schema: + type: string + format: binary + PackageContent.Get.206: + description: > + 206 PARTIAL CONTENT + + + If the NFVO supports range requests, this response shall be returned + when a single consecutive byte range + + from the content of the VNF snapshot package file has been read + successfully according to the request. + + + The response body shall contain the requested part of the VNF snapshot + package file. The "Content-Range" + + HTTP header shall be provided according to IETF RFC 49110 [19]. The + "Content-Type" HTTP header shall be set as + + defined above for the "200 OK" response. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Content-Range: + description: > + The Content-Range response HTTP header indicates where in a full + body message a partial message belongs. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/*: + schema: + type: string + format: binary + PackageContent.Get.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact the "state" of the + VNF snapshot package has a value different from + "AVAILABLE". + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + PackageContent.Get.416: + description: | + 416 Range Not Satisfiable + + Shall be returned upon the following error: The byte + range passed in the "Range" header did not match + any available byte range in the VNF snapshot + package file (e.g. "access after end of file"). + The response body may contain a ProblemDetails + structure + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + IndividualArtifact.Get.200: + description: > + 200 OK + + + Shall be returned when the whole content of the artifact file has been + read successfully. + + + The response body shall include a copy of the artifact file from the VNF + snapshot package. + + The VNF snapshot package format is defined in ETSI GS NFV-SOL 010. + + + The "Content-Type" HTTP header shall be set according to the content + type of the artifact file. + + If the content type cannot be determined, the header shall be set to the + value "application/octet-stream". + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/*: + schema: + type: string + format: binary + IndividualArtifact.Get.206: + description: > + 206 PARTIAL CONTENT + + + If the NFVO supports range requests, this response shall be returned + when a single consecutive byte range + + from the content of the artifact file has been read successfully + according to the request. + + + The response body shall contain the requested part of the artifact file + from the VNF snapshot package. + + The VNF snapshot package is defined in ETSI GS NFV-SOL 010. + + + The "Content-Type" HTTP header shall be set according to the content + type of the artifact file. If the + + content type cannot be determined, the header shall be set to the value + "application/octet-stream". + + + The "Content-Range" HTTP header shall be provided according to IETF RFC + 9110[20]. + headers: + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Content-Range: + description: > + The Content-Range response HTTP header indicates where in a full + body message a partial message belongs. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/*: + schema: + type: string + format: binary + IndividualArtifact.Get.409: + description: | + 409 CONFLICT + + Shall be returned upon the following error: The + operation cannot be executed currently, due to a + conflict with the state of the resource. + Typically, this is due to the fact the "state" of the + VNF snapshot package has a value different from + "AVAILABLE". + The response body shall contain a ProblemDetails + structure, in which the "detail" attribute shall convey + more information about the error. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. Reference: IETF RFC 7231 + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + IndividualArtifact.Get.416: + description: | + 416 Range Not Satisfiable + + Shall be returned upon the following error: The byte + range passed in the "Range" header did not match + any available byte range in the artifact file + (e.g. "access after end of file"). + The response body may contain a ProblemDetails + structure + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the + + corresponding HTTP request has provided an invalid authorization + token. + style: simple + explode: false + schema: + type: string + Version: + description: The used API version. + style: simple + explode: false + schema: + type: string + diff --git a/v5.3.1/SOL003-VirtualisedResourcesQuotaAvailableNotification-API.json b/v5.3.1/SOL003-VirtualisedResourcesQuotaAvailableNotification-API.json new file mode 100644 index 00000000..64af8686 --- /dev/null +++ b/v5.3.1/SOL003-VirtualisedResourcesQuotaAvailableNotification-API.json @@ -0,0 +1 @@ +{"openapi":"3.0.2","info":{"title":"SOL003 - Virtualised Resources Quota Available Notification interface","description":"SOL003 - Virtualised Resources Quota Available Notification interface \n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"1.12.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 003 V5.3.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf"},"servers":[{"url":"http://127.0.0.1/vrqan/v1"},{"url":"https://127.0.0.1/vrqan/v1"}],"paths":{"/api_versions":{"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"This type represents API version information.\n","type":"object","required":["uriPrefix","apiVersions"],"properties":{"uriPrefix":{"description":"Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n","type":"string"},"apiVersions":{"description":"Version(s) supported for the API signaled by the uriPrefix attribute.\n","type":"array","items":{"type":"object","required":["version"],"properties":{"version":{"description":"Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n","type":"string"},"isDeprecated":{"description":"If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n","type":"boolean"},"retirementDate":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}}}}}}}},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the message content of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"405":{"description":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/subscriptions":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"The POST method creates a new subscription. See clause 11.4.2.3.1.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"schema":{"type":"string"}}],"requestBody":{"$ref":"#/components/requestBodies/VrQuotaAvailSubscriptionRequest"},"responses":{"201":{"$ref":"#/components/responses/Subscriptions.Post.201"},"303":{"$ref":"#/components/responses/Subscriptions.Post.303"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":{"$ref":"#/components/responses/Subscriptions.Post.422"},"500":{"description":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"get":{"description":"The GET method queries the list of active subscriptions of the functional block that invokes the method.\nIt can be used e.g. for resynchronization after error situations. See clause 11.4.2.3.2.\n","parameters":[{"$ref":"#/components/parameters/filter_subscriptions"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/Subscriptions.Get.200"},"204":{"$ref":"#/components/responses/Subscriptions.Get.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}},"/subscriptions/{subscriptionId}":{"parameters":[{"$ref":"#/components/parameters/SubscriptionId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method reads an individual subscription. See clause 11.4.3.3.2.\n","responses":{"200":{"$ref":"#/components/responses/IndividualSubscription.Get.200"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}},"delete":{"description":"The DELETE method terminates an individual subscription. See clause 11.4.3.3.5.\n","responses":{"204":{"$ref":"#/components/responses/IndividualSubscription.Delete.204"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the message content contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\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.\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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"401 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"403 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"404 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.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a message content with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"405 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"406 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.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"422 UNPROCESSABLE CONTENT\nIf the message content 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.\nThis 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"500 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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":"503 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 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.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"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","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}}}}}},"components":{"parameters":{"filter_subscriptions":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013 [8]. The NFVO shall support receiving this parameter as part of the URI query string. The VNFM may supply this parameter. All attribute names that appear in the VrQuotaAvailSubscription and in data types referenced from it shall be supported by the NFVO in the filter expression.\n","in":"query","required":false,"schema":{"type":"string"}},"SubscriptionId":{"name":"subscriptionId","in":"path","description":"Identifier of this subscription.\nThis identifier can be retrieved from the resource referenced by the\n\"Location\" HTTP header in the response to a POST request creating a\nnew \"Individual subscription\" resource. It can also be retrieved from the \"id\"\nattribute in the message content of that response.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}}},"requestBodies":{"VrQuotaAvailSubscriptionRequest":{"description":"Details of the subscription to be created.\n","content":{"application/json":{"schema":{"description":"This type represents a subscription request related to notifications related to the availability of the virtualised resources quotas.\n","type":"object","required":["callbackUri"],"properties":{"filter":{"description":"This type represents a subscription filter related to notifications about the availability of the virtualised resources quotas. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n","type":"object","properties":{"vimIds":{"description":"Match VIMs that were created the quota for a consumer of the virtualised resources. This attribute shall only be supported when VNF-related Resource Management in direct mode is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"resourceProviderIds":{"description":"Match the entities responsible for the management of the virtualised resources that were allocated by the NFVO. This attribute shall only be supported when VNF-related Resource Management in indirect mode is applicable. The identification scheme is outside the scope of the present document.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"resourceTypes":{"description":"Match particular resource types.\n","type":"array","items":{"type":"string","enum":["COMPUTE","STORAGE","NETWORK"]}},"resourceGroupIds":{"description":"Match the \"infrastructure resource groups\" that are logical groupings of the virtualised resources assigned to a tenant within an infrastructure Domain.\n","type":"array","items":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE 1 : The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between\n subscriptions. The value of clientPassword should be generated by a random process.\n* NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT which uses mutual authentication based on X.509 certificates, this mode which uses client password to authenticate may be used in the access token request\n toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations\n (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details.\n* NOTE 3: The following values that were included up to version 3.4.1 of the present document have been removed: \"BASIC\" (to signal the use of the basic HTTP authentication) has been removed because it is insecure.\n \"TLS_CERT\" to signal an alternative non-token based authorization method using TLS certificates has been\n removed because the method is no longer supported.\n* NOTE 4: The client certificate is established by means outside the scope of the present document.\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values (see note 3): * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use\n an OAuth 2.0 token, obtained using the client\n credentials grant type after authenticating\n using client identifier and client password\n towards the token endpoint.\n* OAUTH2_CLIENT_CERT: In every HTTP request to the notification endpoint, use an\n OAuth 2.0 token, obtained using the client\n credentials grant type after mutually\n authenticating using client identifier and X.509\n certificates towards the token endpoint.\n","type":"array","items":{"type":"string","enum":["OAUTH2_CLIENT_CREDENTIALS","OAUTH2_CLIENT_CERT"]}},"paramsOauth2ClientCert":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CERT.\nShall be present if authType is \"OAUTH2_CLIENT_CERT\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\n","type":"object","required":["clientId","certificateRef","tokenEndpoint"],"properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint.\n","type":"string"},"certificateRef":{"description":"Fingerprint of the client certificate. The hash function shall use SHA256 or higher. See note 4.\n","type":"string","required":["type","value"],"properties":{"type":{"description":"A string defined in IETF RFC 8259.\n","type":"string"},"value":{"description":"A string defined in IETF RFC 8259.\n","type":"string"}}},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS.\nShall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band.\nShall be absent otherwise.\nSee note 2.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. The client identifier is unique in the scope of the tokenEndpoint. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"clientPassword":{"description":"Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. See note 1.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true}},"responses":{"Subscriptions.Post.201":{"description":"201 CREATED\n\nShall be returned when the subscription has been created successfully.\nThe response body shall contain a representation of the created \"Individual subscription\" resource.\nThe HTTP response shall include a \"Location\" HTTP header that points to the created resource.\n","headers":{"Version":{"description":"The used API version.\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"The resource URI of the created VNF instance\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{"application/json":{"schema":{"description":"This type represents a subscription related to notifications related to the availability of the virtualised resources quotas.\n","type":"object","required":["id","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications about the availability of the virtualised resources quotas. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n","type":"object","properties":{"vimIds":{"description":"Match VIMs that were created the quota for a consumer of the virtualised resources. This attribute shall only be supported when VNF-related Resource Management in direct mode is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"resourceProviderIds":{"description":"Match the entities responsible for the management of the virtualised resources that were allocated by the NFVO. This attribute shall only be supported when VNF-related Resource Management in indirect mode is applicable. The identification scheme is outside the scope of the present document.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"resourceTypes":{"description":"Match particular resource types.\n","type":"array","items":{"type":"string","enum":["COMPUTE","STORAGE","NETWORK"]}},"resourceGroupIds":{"description":"Match the \"infrastructure resource groups\" that are logical groupings of the virtualised resources assigned to a tenant within an infrastructure Domain.\n","type":"array","items":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"_links":{"description":"Links for this resource\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"Subscriptions.Post.303":{"description":"303 See Other\n\nShall be returned when a subscription with\nthe same callback URI and the same filter\nalready exists and the policy of the NFVO\nis to not create redundant subscriptions.\nThe HTTP response shall include a\n\"Location\" HTTP header that contains the\nresource URI of the existing \"Individual\nsubscription\" resource.\nThe response body shall be empty.\n","headers":{"Version":{"description":"The used API version.\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"The resource URI of the created VNF instance\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}}},"Subscriptions.Post.422":{"description":"422 Unprocessable Content\n\nShall be returned upon the following error:\nThe content type of the message content is\nsupported and the message content of a\nrequest contains syntactically correct data\nbut the data cannot be processed.\nThe general cause for this error and its\nhandling is specified in clause 6.4 of ETSI\nGS NFV-SOL 013 [8], including rules for\nthe presence of the response body.\nSpecifically in case of this resource, the\nresponse code 422 shall also be returned\nif the NFVO has tested the Notification\nendpoint as described in clause 11.4.4.3.2\nand the test has failed.\nIn this case, the \"detail\" attribute in the\n\"ProblemDetails\" structure shall convey\nmore information about the error\n","headers":{"Version":{"description":"The used API version.\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, 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 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.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 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"}}}}}},"Subscriptions.Get.200":{"description":"200 OK\n\nShall be returned when the list of subscriptions has been queried successfully.\nThe response body shall contain in an array the representations of all active\nsubscriptions of the functional block that invokes the method, i.e. zero or more\nrepresentations of virtualised resource quota available subscriptions as defined in clause 11.5.2.3.\nIf the \"filter\" URI parameter was supplied in the request, the data in the response body shall\nhave been transformed according to the rules specified in clause 5.2.2 of ETSI GS NFV-SOL 013.\nIf the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013\nfor this resource, inclusion of the Link HTTP header in this response shall follow the provisions\nin clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"Version":{"description":"The used API version.\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a subscription related to notifications related to the availability of the virtualised resources quotas.\n","type":"object","required":["id","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications about the availability of the virtualised resources quotas. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n","type":"object","properties":{"vimIds":{"description":"Match VIMs that were created the quota for a consumer of the virtualised resources. This attribute shall only be supported when VNF-related Resource Management in direct mode is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"resourceProviderIds":{"description":"Match the entities responsible for the management of the virtualised resources that were allocated by the NFVO. This attribute shall only be supported when VNF-related Resource Management in indirect mode is applicable. The identification scheme is outside the scope of the present document.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"resourceTypes":{"description":"Match particular resource types.\n","type":"array","items":{"type":"string","enum":["COMPUTE","STORAGE","NETWORK"]}},"resourceGroupIds":{"description":"Match the \"infrastructure resource groups\" that are logical groupings of the virtualised resources assigned to a tenant within an infrastructure Domain.\n","type":"array","items":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"_links":{"description":"Links for this resource\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}}},"Subscriptions.Get.204":{"description":"No Content\n\nThe notification endpoint was tested successfully.\nThe response body shall be empty.\n","headers":{"Version":{"description":"The used API version.\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualSubscription.Get.200":{"description":"200 OK\n\nShall be returned when information about an individual subscription has been read successfully.\nThe response body shall contain a representation of the \"Individual subscription\" resource.\n","headers":{"Version":{"description":"The used API version.\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a subscription related to notifications related to the availability of the virtualised resources quotas.\n","type":"object","required":["id","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications about the availability of the virtualised resources quotas. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n","type":"object","properties":{"vimIds":{"description":"Match VIMs that were created the quota for a consumer of the virtualised resources. This attribute shall only be supported when VNF-related Resource Management in direct mode is applicable.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"resourceProviderIds":{"description":"Match the entities responsible for the management of the virtualised resources that were allocated by the NFVO. This attribute shall only be supported when VNF-related Resource Management in indirect mode is applicable. The identification scheme is outside the scope of the present document.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"resourceTypes":{"description":"Match particular resource types.\n","type":"array","items":{"type":"string","enum":["COMPUTE","STORAGE","NETWORK"]}},"resourceGroupIds":{"description":"Match the \"infrastructure resource groups\" that are logical groupings of the virtualised resources assigned to a tenant within an infrastructure Domain.\n","type":"array","items":{"description":"An identifier maintained by the VIM or the CISM or other resource provider. It is expected to be unique within the VIM instance.\n","type":"string"}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"_links":{"description":"Links for this resource\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource using an absolute URI.\n","type":"object","required":["href"],"properties":{"href":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualSubscription.Delete.204":{"description":"No Content\n\nShall be returned when the \"Individual subscription\" resource has been deleted successfully.\n","headers":{"Version":{"description":"The used API version.\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Content-Type":{"description":"The MIME type of the body of the response.\n","style":"simple","explode":false,"schema":{"type":"string"}}}}}}} diff --git a/v5.3.1/SOL003-VirtualisedResourcesQuotaAvailableNotification-API.yaml b/v5.3.1/SOL003-VirtualisedResourcesQuotaAvailableNotification-API.yaml new file mode 100644 index 00000000..c5c2e568 --- /dev/null +++ b/v5.3.1/SOL003-VirtualisedResourcesQuotaAvailableNotification-API.yaml @@ -0,0 +1,6522 @@ +openapi: 3.0.2 +info: + title: SOL003 - Virtualised Resources Quota Available Notification interface + description: | + SOL003 - Virtualised Resources Quota Available Notification interface + + 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/rep/nfv/SOL002-SOL003/issues + contact: + name: NFV-SOL WG + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' + version: '1.12.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' +externalDocs: + description: ETSI GS NFV-SOL 003 V5.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/05.03.01_60/gs_NFV-SOL003v050301p.pdf +servers: + - url: 'http://127.0.0.1/vrqan/v1' + - url: 'https://127.0.0.1/vrqan/v1' +paths: + /api_versions: + get: + description: > + The GET method reads API version information. This method shall follow + the provisions specified in SOL013 table 9.3.3.3.2-1 for request and + response data structures, and response codes. URI query parameters are + not supported. + responses: + '200': + description: > + API version information was read successfully. The response body + shall contain API version information, as defined in clause 7.1.6. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the message content of a request is larger than the amount of + data the API producer is willing or able to process, it shall + respond with this response code, following the provisions in IETF + RFC 7231 for the use of the "Retry-After" HTTP header and for + closing the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + post: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + put: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + This method is not supported. When this method is requested on this + resource, the API producer shall return a "405 Method Not Allowed" + response as defined in SOL013 clause 6.4. + responses: + '405': + description: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + /subscriptions: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + post: + description: | + The POST method creates a new subscription. See clause 11.4.2.3.1. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + $ref: '#/components/requestBodies/VrQuotaAvailSubscriptionRequest' + responses: + '201': + $ref: '#/components/responses/Subscriptions.Post.201' + '303': + $ref: '#/components/responses/Subscriptions.Post.303' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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': + $ref: '#/components/responses/Subscriptions.Post.422' + '500': + description: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + get: + description: > + The GET method queries the list of active subscriptions of the + functional block that invokes the method. + + It can be used e.g. for resynchronization after error situations. See + clause 11.4.2.3.2. + parameters: + - $ref: '#/components/parameters/filter_subscriptions' + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the VNFM if the VNFM supports alternative 2 (paging) + according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this + resource. + in: query + required: false + schema: + type: string + responses: + '200': + $ref: '#/components/responses/Subscriptions.Get.200' + '204': + $ref: '#/components/responses/Subscriptions.Get.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '/subscriptions/{subscriptionId}': + parameters: + - $ref: '#/components/parameters/SubscriptionId' + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + get: + description: | + The GET method reads an individual subscription. See clause 11.4.3.3.2. + responses: + '200': + $ref: '#/components/responses/IndividualSubscription.Get.200' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + delete: + description: > + The DELETE method terminates an individual subscription. See clause + 11.4.3.3.5. + responses: + '204': + $ref: '#/components/responses/IndividualSubscription.Delete.204' + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the message + content contains a syntactically incorrect data structure), the API + producer shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + If there is an application error related to the client's input that + cannot be easily mapped to any other HTTP response code ("catch all + error"), the API producer shall respond with this response code. The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + + If the request contains a malformed access token, the API producer + should respond with this response. The details of the error shall be + returned in the WWW Authenticate HTTP header, as defined in IETF RFC + 6750 and IETF RFC 7235. The ProblemDetails structure may be + provided. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 401 UNAUTHORIZED + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 403 FORBIDDEN + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 404 NOT FOUND + + If the API producer did not find a current representation for the + resource addressed by the URI passed in the request or is not + willing to disclose that one exists, it shall respond with this + response code. The "ProblemDetails" structure may be provided, + including in the "detail" attribute information about the source of + the problem, e.g. a wrong resource URI variable. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a message content with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 405 METHOD NOT ALLOWED + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 406 NOT ACCEPTABLE + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 422 UNPROCESSABLE CONTENT + + If the message content of a request contains syntactically correct + data (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 500 INTERNAL SERVER ERROR + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond with this response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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: > + 503 SERVICE UNAVAILABLE + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 for the use + of the "Retry-After" HTTP header and for the alternative to refuse + the connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + 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. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 is reproduced inthis structure. Compared to + the general framework defined in IETF RFC 7807, 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 + 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 +components: + parameters: + filter_subscriptions: + name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI GS + NFV-SOL 013 [8]. The NFVO shall support receiving this parameter as part + of the URI query string. The VNFM may supply this parameter. All + attribute names that appear in the VrQuotaAvailSubscription and in data + types referenced from it shall be supported by the NFVO in the filter + expression. + in: query + required: false + schema: + type: string + SubscriptionId: + name: subscriptionId + in: path + description: > + Identifier of this subscription. + + This identifier can be retrieved from the resource referenced by the + + "Location" HTTP header in the response to a POST request creating a + + new "Individual subscription" resource. It can also be retrieved from + the "id" + + attribute in the message content of that response. + required: true + style: simple + explode: false + schema: + type: string + requestBodies: + VrQuotaAvailSubscriptionRequest: + description: | + Details of the subscription to be created. + content: + application/json: + schema: + description: > + This type represents a subscription request related to + notifications related to the availability of the virtualised + resources quotas. + type: object + required: + - callbackUri + properties: + filter: + description: > + This type represents a subscription filter related to + notifications about the availability of the virtualised + resources quotas. At a particular nesting level in the filter + structure, the following applies: All attributes shall match + in order for the filter to match (logical "and" between + different filter attributes). If an attribute is an array, the + attribute shall match if at least one of the values in the + array matches (logical "or" between the values of one filter + attribute). + type: object + properties: + vimIds: + description: > + Match VIMs that were created the quota for a consumer of + the virtualised resources. This attribute shall only be + supported when VNF-related Resource Management in direct + mode is applicable. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderIds: + description: > + Match the entities responsible for the management of the + virtualised resources that were allocated by the NFVO. + This attribute shall only be supported when VNF-related + Resource Management in indirect mode is applicable. The + identification scheme is outside the scope of the present + document. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceTypes: + description: | + Match particular resource types. + type: array + items: + type: string + enum: + - COMPUTE + - STORAGE + - NETWORK + resourceGroupIds: + description: > + Match the "infrastructure resource groups" that are + logical groupings of the virtualised resources assigned to + a tenant within an infrastructure Domain. + type: array + items: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + authentication: + description: > + * NOTE 1 : The clientId and clientPassword passed in a + subscription shall not be the same as the clientId and + clientPassword that are used to obtain authorization for API requests. Client credentials may differ between + subscriptions. The value of clientPassword should be generated by a random process. + * NOTE 2: As a less secure alternative to OAUTH2_CLIENT_CERT + which uses mutual authentication based on X.509 + certificates, this mode which uses client password to authenticate may be used in the access token request + toward the authorization server (as defined by IETF RFC 6749 [7]), only to support legacy implementations + (version 3.4.1 or earlier version of the present document). See clause 8.1 for more details. + * NOTE 3: The following values that were included up to + version 3.4.1 of the present document have been removed: + "BASIC" (to signal the use of the basic HTTP authentication) has been removed because it is insecure. + "TLS_CERT" to signal an alternative non-token based authorization method using TLS certificates has been + removed because the method is no longer supported. + * NOTE 4: The client certificate is established by means + outside the scope of the present document. + type: object + required: + - authType + properties: + authType: + description: > + Defines the types of Authentication / Authorization which + the API consumer is willing to accept when receiving a + notification. Permitted values (see note 3): * + OAUTH2_CLIENT_CREDENTIALS: In every + HTTP request to the notification endpoint, use + an OAuth 2.0 token, obtained using the client + credentials grant type after authenticating + using client identifier and client password + towards the token endpoint. + * OAUTH2_CLIENT_CERT: In every HTTP + request to the notification endpoint, use an + OAuth 2.0 token, obtained using the client + credentials grant type after mutually + authenticating using client identifier and X.509 + certificates towards the token endpoint. + type: array + items: + type: string + enum: + - OAUTH2_CLIENT_CREDENTIALS + - OAUTH2_CLIENT_CERT + paramsOauth2ClientCert: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CERT. + + Shall be present if authType is "OAUTH2_CLIENT_CERT" and + the contained information has not been provisioned out of + band. + + Shall be absent otherwise. + type: object + required: + - clientId + - certificateRef + - tokenEndpoint + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. + type: string + certificateRef: + description: > + Fingerprint of the client certificate. The hash + function shall use SHA256 or higher. See note 4. + type: string + required: + - type + - value + properties: + type: + description: | + A string defined in IETF RFC 8259. + type: string + value: + description: | + A string defined in IETF RFC 8259. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + paramsOauth2ClientCredentials: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CREDENTIALS. + + Shall be present if authType is + "OAUTH2_CLIENT_CREDENTIALS" and the contained information + has not been provisioned out of band. + + Shall be absent otherwise. + + See note 2. + type: object + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. The client identifier is unique in the scope of + the tokenEndpoint. Shall be present if it has not been + provisioned out of band. See note 1. + type: string + clientPassword: + description: > + Client password to be used in the access token request + of the OAuth 2.0 client credentials grant type. Shall + be present if it has not been provisioned out of band. + See note 1. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + required: true + responses: + Subscriptions.Post.201: + description: > + 201 CREATED + + + Shall be returned when the subscription has been created successfully. + + The response body shall contain a representation of the created + "Individual subscription" resource. + + The HTTP response shall include a "Location" HTTP header that points to + the created resource. + headers: + Version: + description: | + The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: | + The resource URI of the created VNF instance + style: simple + explode: false + schema: + type: string + format: url + content: + application/json: + schema: + description: > + This type represents a subscription related to notifications + related to the availability of the virtualised resources quotas. + type: object + required: + - id + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: > + This type represents a subscription filter related to + notifications about the availability of the virtualised + resources quotas. At a particular nesting level in the filter + structure, the following applies: All attributes shall match + in order for the filter to match (logical "and" between + different filter attributes). If an attribute is an array, the + attribute shall match if at least one of the values in the + array matches (logical "or" between the values of one filter + attribute). + type: object + properties: + vimIds: + description: > + Match VIMs that were created the quota for a consumer of + the virtualised resources. This attribute shall only be + supported when VNF-related Resource Management in direct + mode is applicable. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderIds: + description: > + Match the entities responsible for the management of the + virtualised resources that were allocated by the NFVO. + This attribute shall only be supported when VNF-related + Resource Management in indirect mode is applicable. The + identification scheme is outside the scope of the present + document. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceTypes: + description: | + Match particular resource types. + type: array + items: + type: string + enum: + - COMPUTE + - STORAGE + - NETWORK + resourceGroupIds: + description: > + Match the "infrastructure resource groups" that are + logical groupings of the virtualised resources assigned to + a tenant within an infrastructure Domain. + type: array + items: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + _links: + description: | + Links for this resource + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + Subscriptions.Post.303: + description: | + 303 See Other + + Shall be returned when a subscription with + the same callback URI and the same filter + already exists and the policy of the NFVO + is to not create redundant subscriptions. + The HTTP response shall include a + "Location" HTTP header that contains the + resource URI of the existing "Individual + subscription" resource. + The response body shall be empty. + headers: + Version: + description: | + The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Location: + description: | + The resource URI of the created VNF instance + style: simple + explode: false + schema: + type: string + format: url + Subscriptions.Post.422: + description: | + 422 Unprocessable Content + + Shall be returned upon the following error: + The content type of the message content is + supported and the message content of a + request contains syntactically correct data + but the data cannot be processed. + The general cause for this error and its + handling is specified in clause 6.4 of ETSI + GS NFV-SOL 013 [8], including rules for + the presence of the response body. + Specifically in case of this resource, the + response code 422 shall also be returned + if the NFVO has tested the Notification + endpoint as described in clause 11.4.4.3.2 + and the test has failed. + In this case, the "detail" attribute in the + "ProblemDetails" structure shall convey + more information about the error + headers: + Version: + description: | + The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807, 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 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. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 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 + Subscriptions.Get.200: + description: > + 200 OK + + + Shall be returned when the list of subscriptions has been queried + successfully. + + The response body shall contain in an array the representations of all + active + + subscriptions of the functional block that invokes the method, i.e. zero + or more + + representations of virtualised resource quota available subscriptions as + defined in clause 11.5.2.3. + + If the "filter" URI parameter was supplied in the request, the data in + the response body shall + + have been transformed according to the rules specified in clause 5.2.2 + of ETSI GS NFV-SOL 013. + + If the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 + of ETSI GS NFV-SOL 013 + + for this resource, inclusion of the Link HTTP header in this response + shall follow the provisions + + in clause 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + Version: + description: | + The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + type: array + items: + description: > + This type represents a subscription related to notifications + related to the availability of the virtualised resources quotas. + type: object + required: + - id + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: > + This type represents a subscription filter related to + notifications about the availability of the virtualised + resources quotas. At a particular nesting level in the + filter structure, the following applies: All attributes + shall match in order for the filter to match (logical "and" + between different filter attributes). If an attribute is an + array, the attribute shall match if at least one of the + values in the array matches (logical "or" between the values + of one filter attribute). + type: object + properties: + vimIds: + description: > + Match VIMs that were created the quota for a consumer of + the virtualised resources. This attribute shall only be + supported when VNF-related Resource Management in direct + mode is applicable. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderIds: + description: > + Match the entities responsible for the management of the + virtualised resources that were allocated by the NFVO. + This attribute shall only be supported when VNF-related + Resource Management in indirect mode is applicable. The + identification scheme is outside the scope of the + present document. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceTypes: + description: | + Match particular resource types. + type: array + items: + type: string + enum: + - COMPUTE + - STORAGE + - NETWORK + resourceGroupIds: + description: > + Match the "infrastructure resource groups" that are + logical groupings of the virtualised resources assigned + to a tenant within an infrastructure Domain. + type: array + items: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + _links: + description: | + Links for this resource + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + Subscriptions.Get.204: + description: | + No Content + + The notification endpoint was tested successfully. + The response body shall be empty. + headers: + Version: + description: | + The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + IndividualSubscription.Get.200: + description: > + 200 OK + + + Shall be returned when information about an individual subscription has + been read successfully. + + The response body shall contain a representation of the "Individual + subscription" resource. + headers: + Version: + description: | + The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + content: + application/json: + schema: + description: > + This type represents a subscription related to notifications + related to the availability of the virtualised resources quotas. + type: object + required: + - id + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: > + This type represents a subscription filter related to + notifications about the availability of the virtualised + resources quotas. At a particular nesting level in the filter + structure, the following applies: All attributes shall match + in order for the filter to match (logical "and" between + different filter attributes). If an attribute is an array, the + attribute shall match if at least one of the values in the + array matches (logical "or" between the values of one filter + attribute). + type: object + properties: + vimIds: + description: > + Match VIMs that were created the quota for a consumer of + the virtualised resources. This attribute shall only be + supported when VNF-related Resource Management in direct + mode is applicable. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceProviderIds: + description: > + Match the entities responsible for the management of the + virtualised resources that were allocated by the NFVO. + This attribute shall only be supported when VNF-related + Resource Management in indirect mode is applicable. The + identification scheme is outside the scope of the present + document. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + resourceTypes: + description: | + Match particular resource types. + type: array + items: + type: string + enum: + - COMPUTE + - STORAGE + - NETWORK + resourceGroupIds: + description: > + Match the "infrastructure resource groups" that are + logical groupings of the virtualised resources assigned to + a tenant within an infrastructure Domain. + type: array + items: + description: > + An identifier maintained by the VIM or the CISM or + other resource provider. It is expected to be unique + within the VIM instance. + type: string + callbackUri: + description: | + String formatted according to IETF RFC 3986. + type: string + _links: + description: | + Links for this resource + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + IndividualSubscription.Delete.204: + description: > + No Content + + + Shall be returned when the "Individual subscription" resource has been + deleted successfully. + headers: + Version: + description: | + The used API version. + style: simple + explode: false + schema: + type: string + 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. + style: simple + explode: false + schema: + type: string + Content-Type: + description: | + The MIME type of the body of the response. + style: simple + explode: false + schema: + type: string + -- GitLab